Have been getting an the worst of all possible worlds, an intermittent error, see image
Application is an interface to, and will not run without being connected to, an arduino which has Grbl1.1 loaded. Full code is available in https://github.com/TPMoyer/Grbl4P.
App was built with G4P GUI Builder4.4.1 atop G4P 4.3.6. Have been getting similar occurrence frequency on a gamer windows workstation development box, and a Raspberry Pi 4 CNC controller.
No interaction through the GUI seems to trigger the error. I occurs sometimes when I am actively clicking buttons and prompting the motors to move, and will also happen when the app is in idle… simply asking the GRBL for a status at 5 hz. Confess to not having noticed if the launch-off point from my code into the the sun.reflect.DelegatingMeghodAccessorImpl.invoe(DelegatingMethodAccessorImpl.java:43 is always PApplet.java:1432 or not. Would glomming everything into a single .pde be helpful to allow pinpointing this jumping off point?
Would be happy if I could simply try-catch the error.
OK I have looked at the stack trace and it suggests the probable cause of the NPE.
The interesting part is in lines 2-5 which start with at g4p_controls...
Line 5 : GWindowImpl.draw which is responsible for calling the draw() method for all G4P controls on the main sketch window.
Line 4: GLabel.draw this is responsible for drawing a GLabel
Line 3: GLabel.update all G4P controls have an offscreen graphics buffer and this method will update the buffer if its state has changed.
Line 2: StyledString.getLines is called when the label text has been change since last drawn. It formats the text and draws it to the buffer.
So the NPE is thrown in StyledString.getLines and to be honest this shouldn’t happen and no one else has reported similar problems. I have tried but I cannot reproduce the error.
The only thing I can think of at the moment is that the label’s text is being changed while it attempts to draw it. Is your application single threaded or are you processing serial events on a separate thread?
Am using the asyncronous SerialEvent() method to interact with the arduino/grbl, so your proposed simultaneous change & draw could occur.
Will poke around with buffering label (and other GUI control) changes in their current SerialEvent() location. Proposal would be to flush the queue to the G4P setXXX methods only within the draw function.
Your insight has the ring of truth about it.
Thanks.
Try
synchronized void draw(){
...
}
and / or do the same for the serialEvent method. I am not an expert in concurrent processing but it might just do the trick.