G4P java Concurrent Modification Exception Error when exit() called

Processing Libraries
21

Hi Peter, thanks for the wealth of ideas!

Based on what you had shared previously, I really looked again hard at the code to try to figure out what was being “concurrently modified.” And I realized I was looking in the wrong place. I was trying to see what was being modified in the GWindow, not realizing the GWindow was modifying the main sketch window! I was looking at it backwards.

When I saw that, I put a noLoop() in front of the offending code, and a loop() after, and the concurrent errors seem to have gone! Time will tell. But that’s based on your comment that it’s the draw method that gets angry when it’s messed with outside of the main sketch. That’s why I tried the noLoop deal. Which seems to work…I’ll post back if it still breaks.

This doesn’t solve the issue of a robust messaging solution, however.

From the sounds of your message, I would think asynchronous dialogs would be better - modal really, so nothing can be done outside the box until it’s dismissed - because in all actuality the user should not be doing anything in the main window if a dialog box is open first.

In fact I also tried disabling all the controls on the main window when a GWindow is open, but that also failed - because if the user clicks the “x” to close the window from the OS, then my code to reenable the controls on the main window weren’t called, and the app was dead. And I don’t know how to call a function when a GWindow is closed - is there a callback for that, if the user clicks the OS “x” and closes it without using a button?

This is a REALLY tricky thing to do well!!! I mean it’s one thing to cobble together a few lines of code to get something done, and quite another to develop a robust app that is well behaved. I have such hugely massive respect for programmers now!!!

I have already reduced the windows needed to about 5 - I was exaggerating when I said 47 but it felt like it. So I’m reusing 5 windows and attaching different event handlers depending on how it’s called.

Kludgy. Incredibly kludgy and messy. It works. But I’m not proud of it. It means part of the code that called the dialog has to finish in the dialog box code. Truly horrible.

I’m certain I can do this better. I will keep thinking about it. Maybe I just need to make some global variables to capture user selections for button for each window and handle it that way. Don’t know why I didn’t think of that before.

Honestly it would be amazing if someone created a robust modal messaging library, complete with the ability to add custom icons, play sounds, control the buttons that appear, and capture user interactions with the buttons. That’s not a hint by the way :slight_smile:

But as you say, Processing was never designed as a full blown language to handle this sort of thing.

I feel like Processing is such an odd duck. While in some ways it is incredibly robust and powerful, in other ways it so misses the mark on basic needs for creating robust apps (which was NOT the design goal, I know!).

But then why all the advanced features too? Again, it’s so odd. But so cool too.

In any case, as always, many thanks for your insights. If you have any other thoughts I’d love to hear them, but I value your time, and you’ve already been so generous. So that’s me saying “THANKS AGAIN!!!”

22

Oh, I was thinking more about this, and I think you might be onto something with synchronous.

Because when a dialog box is open, I don’t want the main sketch to keep running - I want it to wait for the user to click OK or CANCEL or YES or NO - and then grab their response. That’s why I didn’t implement global variables before, because there’s no way to grab the results of an interaction if the calling routine keeps running.

So, is there a way to create synchronous GWindows? Or similar?

With the added advantage that it is automatically modal - nothing can be done outside of it because the main sketch halts. And as you said, no concurrent modification errors…

Thank you again!!

Mike

23

This is an absolute no-no never attempt to change values in another thread window. If you avoid this you should avoid concurrent errors :grin: Since you have found the cause you should be safe using GWindows although it doesn’t do exactly what you would like.

I think you mean synchronous for most situations this would be best and easiest to implement

You might try this method LOL

No to the first question and yes to the second question but it would be challenging but something on the lines of GPanel but configurable would be the way forward,

1 Like
24

Well you’ve managed to give me a wealth of information and support, again!!

Especially thank you for the onCloseEventHandler - this is invaluable! I do spend time in your documentation, but I get lost pretty quickly. Believe it or not I actually try to figure things out before asking you (although the sheer number of questions I have asked you would suggest differently!).

If we ever meet in person and food or drink is involved, it’s on me!

Thank you so much Peter!!!

You are truly amazing. :smiling_face_with_three_hearts:

Mike

25

I’m trying to use the addOnCloseHandler() - but I see this only works if you use the CLOSE_WINDOW method. If I use CLOSE_WINDOW then when I show the window again it’s in a dead state - the controls and buttons are non-responsive, although the app doesn’t crash - so I’ve been using the HIDE_WINDOW method which works great.

How can I use the HIDE_WINDOW method but also capture when the user clicks the “x” to close the window instead of using the button (which hides the window)?

Sorry to be dense…I could find only one reference to “hide” in the documentation search feature…

Mike

26

That is as it should be.

If you create a GWindow using a global variable windowIf you close of force close the window with

window.close();
// or 
window.forceClose();
// but NOT both LOL

Then G4P will disable every thing about the window but Java will not garbage collect the memory used because there is still a reference to the window. After closing the window immediately follow up with

window = null;

Damm! … I wrote all this stuff and I can’t remember half of whats in G4P.

If I remember correctly the method specified by addOnCloseHandler() will be executed when the “x” is clicked,

1 Like
27

HIDE_WINDOW and CLOSE_WINDOW are not methods / functions that are simple constants that specify what should happen when you call

window.close();

Note forceClose() ignores these constants and cloases the window anyway.

2 Likes
28

I don’t always remember what I had for breakfast; go easy on yourself man! :slight_smile:

The addOnCloseHandler() is not being called when the “x” is clicked, even though I’ve added it as an event handler with window.addOnCloseHandler(this, "windowClose");

Perhaps I’m not implementing it correctly.

For the function itself, I have this:
public void windowClose(GWindow source) { //code }

I am trying to understand the documentation - is it correct to use the above statement for the callback function?

Thank you again; sorry to keep asking you q’s.

Mike