Getting java exception in G4P while creating child window

I think I know what the problem is, I just wanted to get a second opinion. This is by far the most complex window I’ve tried to create so far. Sometimes it comes up OK and sometimes I get a “java.util.ConcurrentModificationException” error. I think it’s because there are so many controls in this window (which I’m saving in various arrays) that sometimes the next Processing display loop starts before it has time to create them all. I’m not deleting or inserting any elements in the arrays, I’m just assigning newly created controls to the elements of the arrays. (The small circles are GImageToggleButton’s.) And sometimes the window comes up without any error, but some of the controls are missing.

I googled for this error and found some suggestions about using ‘pre()’ routines to solve the issue. I’ve never used ‘pre()’ routines in Processing. Do you think that might help? I tried setting the frame rate as low as 20 fps, but that didn’t seem to help much (maybe just a little).


1 Like

@quark I think I found the problem. When I replaced all the GImageToggleButton’s with GCheckbox’s, the window opened without any problem. Could it have something to do with opening the image file? I’m creating 369 of these controls, so maybe that’s what is causing the problem (although I don’t understand how the error message relates to it).

Even if it isn’t the cause, is there some way to create a new GImageToggleButton from a pre-loaded image, instead of loading it from a file? It would at least be more efficient, I think. (It might be necessary to add a new constructor to do this. Would that be a lot of work?) I haven’t looked into it yet, but there’s probably a method to read an image from a file into memory that I could use. Then I’d only have to read the file once instead of 369 times.

G4P already caches image files so if you attempt to load the same file multiple times, the first time is is read in after that it comes from the cache.

If you are creating a GWindow with many controls then use noLoop() and loop() like this

window = GWindow.getWindow(blah blah blah);
// Create all the controls for this window
1 Like

Thanks, that worked. I guess it takes longer to create an instance of GImageToggleButton (even if the image is being cached) than it does to create an instance of GCheckbox, because it wasn’t necessary to wrap up the creation of the checkboxes between ‘noLoop()’ and ‘loop()’. But from now on, I’ll always add noLoop()/loop() when creating a child window.

@quark I thought the problem was solved, but I still get an occasional exception. I found that by adding calls to delay() in the function that creates the window, it seems to help. But I don’t understand why. Does the G4P library or the underlying Java functions make use of multi-threading to initialize arrays? My code should be running sequentially, so I don’t see why calling ‘delay()’ should make any difference. Also, a delay of a few seconds seems to take care of it, but if the code runs on a slower machine, it may not be enough.

I also get this exception when closing the sketch sometimes:

java.lang.IllegalStateException: Buffers have not been created
	at java.awt.Component$FlipBufferStrategy.getBackBuffer(
	at java.awt.Component$FlipBufferStrategy.updateInternalBuffers(
	at java.awt.Component$FlipBufferStrategy.revalidate(
	at java.awt.Component$FlipBufferStrategy.revalidate(
	at java.awt.Component$FlipBufferStrategy.getDrawGraphics(
	at processing.awt.PSurfaceAWT.render(
IllegalStateException: Buffers have not been created
	at processing.awt.PSurfaceAWT$12.callDraw(
	at processing.core.PSurfaceNone$

I suppose I could ignore this because it doesn’t happen until I close the sketch, but it doesn’t look very good, and it may be an indication of a bigger problem that may cause issues while the sketch is still running. Any suggestions?

No matter which library you use to create multiple windows it is all the same. Every window created is effectively another Processing Sketch with its own event-despatch-thread and to close a window requires an event to be fired and processed on its own EDT. So when the application is closed you cannot predict the order that the system will actually dispoae of the windows. Putting a delay on the main Processing thread might help to make sure the secondary windows are disposed of first.

You might try adding this to your main Processing sketch

void exit(){
  // Assuming we have a GWindow called win then 

Don’t know if it will help but can’t hurt trying :pray:


Thanks, that got rid of the IllegalStateException error when closing the sketch.

I’ve almost finished the Processing code. Soon I’ll start working on the Pure Data code so the sketch will actually do something. That’s when the real fun should begin!