# Getting java exception in G4P while creating child window

**URL:** <https://discourse.processing.org/t/getting-java-exception-in-g4p-while-creating-child-window/20882>\
**Category:** Libraries\
**Created:** [May 14, 2020, 6:31pm UTC](https://discourse.processing.org/t/getting-java-exception-in-g4p-while-creating-child-window/20882 "2020-05-14T18:31:48Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![David](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/david/32/8853_2.png) [@David](https://discourse.processing.org/u/David)\
**Post date:** [May 14, 2020, 6:31pm UTC](https://discourse.processing.org/t/getting-java-exception-in-g4p-while-creating-child-window/20882/1 "2020-05-14T18:31:48Z")

</div>

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).

Thanks.!  
[PatchWindow|690x315](https://discourse.processing.org/uploads/short-url/hHbqVsy4uS4EHSYM728k5JHkeL4.png)

---

<div class="post-metadata">

**Author:** ![David](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/david/32/8853_2.png) [@David](https://discourse.processing.org/u/David)\
**Post date:** [May 16, 2020, 10:31am UTC](https://discourse.processing.org/t/getting-java-exception-in-g4p-while-creating-child-window/20882/2 "2020-05-16T10:31:41Z")

</div>

@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.

---

<div class="post-metadata">

**Author:** ![quark](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/quark/32/26_2.png) [@quark](https://discourse.processing.org/u/quark)\
**Post date:** [May 16, 2020, 11:53am UTC](https://discourse.processing.org/t/getting-java-exception-in-g4p-while-creating-child-window/20882/3 "2020-05-16T11:53:56Z")

</div>

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

```auto
window = GWindow.getWindow(blah blah blah);
window.noLoop();
// Create all the controls for this window
window.loop();

```

---

<div class="post-metadata">

**Author:** ![David](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/david/32/8853_2.png) [@David](https://discourse.processing.org/u/David)\
**Post date:** [May 16, 2020, 3:31pm UTC](https://discourse.processing.org/t/getting-java-exception-in-g4p-while-creating-child-window/20882/4 "2020-05-16T15:31:17Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![David](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/david/32/8853_2.png) [@David](https://discourse.processing.org/u/David)\
**Post date:** [May 17, 2020, 12:25pm UTC](https://discourse.processing.org/t/getting-java-exception-in-g4p-while-creating-child-window/20882/5 "2020-05-17T12:25:33Z")

</div>

@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:

```auto
java.lang.IllegalStateException: Buffers have not been created
	at sun.awt.windows.WComponentPeer.getBackBuffer(WComponentPeer.java:1018)
	at java.awt.Component$FlipBufferStrategy.getBackBuffer(Component.java:4065)
	at java.awt.Component$FlipBufferStrategy.updateInternalBuffers(Component.java:4050)
	at java.awt.Component$FlipBufferStrategy.revalidate(Component.java:4165)
	at java.awt.Component$FlipBufferStrategy.revalidate(Component.java:4147)
	at java.awt.Component$FlipBufferStrategy.getDrawGraphics(Component.java:4139)
	at processing.awt.PSurfaceAWT.render(PSurfaceAWT.java:298)
IllegalStateException: Buffers have not been created
	at processing.awt.PSurfaceAWT$12.callDraw(PSurfaceAWT.java:1548)
	at processing.core.PSurfaceNone$AnimationThread.run(PSurfaceNone.java:313)

```

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?

---

<div class="post-metadata">

**Author:** ![quark](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/quark/32/26_2.png) [@quark](https://discourse.processing.org/u/quark)\
**Post date:** [May 17, 2020, 5:21pm UTC](https://discourse.processing.org/t/getting-java-exception-in-g4p-while-creating-child-window/20882/6 "2020-05-17T17:21:28Z")

</div>

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

```auto
void exit(){
  // Assuming we have a GWindow called win then 
  win.noLoop();
  super.exit();
}

```

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

---

<div class="post-metadata">

**Author:** ![David](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/david/32/8853_2.png) [@David](https://discourse.processing.org/u/David)\
**Post date:** [May 17, 2020, 6:19pm UTC](https://discourse.processing.org/t/getting-java-exception-in-g4p-while-creating-child-window/20882/7 "2020-05-17T18:19:10Z")

</div>

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!