Go Down

Topic: noDisplay() messes up Arduino IDE on MacBook Pro Retina (Read 2144 times) previous topic - next topic


May 06, 2013, 02:20 am Last Edit: May 06, 2013, 03:46 pm by graymalk Reason: 1

The following causes the IDE to become unusable on a MacBook Pro with Retina Display:


You just have to type that anywhere in the sketch in uncommented code and the IDE will become extremely difficult to use after that.  In fact, you just have to type noDisplay by itself, without an object or the ".();".  The exact symptoms are the following:
1.  The line with noDisplay in it will disappear starting from the noDisplay part and going rightwards
2.  Several lines after that may get screwed up visually.  They may not screw up initially but they will if you start freaking out and trying to move the cursor around and do things.
3.  The cursor will seem to move all around the window.  (IIRC this is caused by attempting to move the cursor around to find your code - I admit I haven't tried it in a while because it's frustrating to fix the problem if you get your real cursor too far away from the offending line)
4.  Scrolling causes more lines to disappear.

It doesn't mess up the file - as in, you can still go by memory of where your cursor was and move it around and all disappeared lines will still be there, or you can just hit undo.  If you comment out the noDisplay line, your text will immediately reappear (including the commented noDisplay line) and go back to normal.  I've been googling about this for a few months and have never turned anything up, so I guess I'm the only one with this problem.  I've downloaded different versions of the IDE and they all do the same thing.  It doesn't happen on my other systems - just my MacBook Pro with Retina display, running OS 10.8.

I will soon be finding out if it can compile with this offending line in it because I really need it for a sketch.  Up until now, I've been able to avoid using it, but my current project will need it to keep power usage down.  I do have Windows machines I can use instead but the MBP is by far my most favourite machine I've ever owned.  I use it for everything as much as possible.

Thanks for reading!

P.S.  The opposite command, display(), works fine.  In fact I haven't come across anything else that causes this issue.

Oh and if this is a known problem with a known solution and I was just too stupid to find it, please point me in the right direction.

Java version:  WAS 1.6, updated to 1.7 (sacrificed Chrome for that - hello FireFox).  Terminal still reports 1.6, though, and I don't know why.  The Java control panel is now installed and says it's running 1.7.  Maybe both versions are still installed.  I don't know if I can change that.  Anyway, problem persists.

Edited:  I was a bit wrong about a couple of the details.  Added Java info.


I forgot that it also spits out a tremendous number of errors in the bottom of the IDE when this happens.  I'll include a code snippet and a copy/paste of the error output.  Note that the error output is continuous and only stops when you re-comment the offending line, so what I'm including here may either be repetitive or incomplete.  I tried to just get one unique set of errors.

Code snippet:
Code: [Select]

  if (menuSelection == OFF) // turn off OLED
  //  lcd.noDisplay(); // <-- offending line

The errors:
Code: [Select]
Error repainting line range {99,99}:
java.lang.ArrayIndexOutOfBoundsException: 73
at processing.app.syntax.SyntaxUtilities.paintSyntaxLine(SyntaxUtilities.java:151)
at processing.app.syntax.TextAreaPainter.paintSyntaxLine(TextAreaPainter.java:647)
at processing.app.syntax.TextAreaPainter.paintLine(TextAreaPainter.java:606)
at processing.app.syntax.TextAreaPainter.paint(TextAreaPainter.java:415)
at javax.swing.JComponent._paintImmediately(JComponent.java:5106)
at javax.swing.JComponent.paintImmediately(JComponent.java:4890)
at javax.swing.RepaintManager$3.run(RepaintManager.java:814)
at javax.swing.RepaintManager$3.run(RepaintManager.java:802)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:802)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:745)
at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:725)
at javax.swing.RepaintManager.access$1000(RepaintManager.java:46)
at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1684)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:708)
at java.awt.EventQueue.access$400(EventQueue.java:82)
at java.awt.EventQueue$2.run(EventQueue.java:669)
at java.awt.EventQueue$2.run(EventQueue.java:667)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:678)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:296)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:211)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:201)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:196)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:188)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)


May 06, 2013, 04:16 am Last Edit: May 06, 2013, 05:05 am by graymalk Reason: 1
And finally, to make my life easier, I realized eventually that I could just go edit the libraries and change the command.  I now call it nodisplay().   ]:D  Works like a charm.  It obviously doesn't solve the problem but it lets me work in peace.

Edit:  In fact, I've gone so far as to just duplicate the functions in the libraries I have.  I have the bigger LiquidCrystal library that can handle shift registers, and the Adafruit OLED library.  Those were super easy to modify.  The system library is more difficult as I don't know where those get stored in the Mac version, but I don't use that one anyway, ever.  Anyway, I now have both nodisplay() and noDisplay(), and both work interchangeably and code written to use either will work fine on any of my computers.  Problem successfully worked around.

Coding Badly

May 06, 2013, 09:59 am Last Edit: May 06, 2013, 10:04 am by Coding Badly Reason: 1

I believe the problem stems from a corrupt[font=Courier New] keywords.txt [/font]file.

...yup... http://arduino.cc/forum/index.php?topic=22943.0


That was it!  Awesome!  Thank you!  I'm changing the title to reflect that it's not a bug.

Go Up