This happened to me a couple of times:
While doing some operation in the G4P gui builder tool the tool just hangs with a fancy java exception in the console. When I close everything and start again nothing works due to what looks like a corrupted parameter in the GUI_BUILDER_DATA/gui.ser.4.3 file or a file inconsistency between the sketch and parameters stored in that file.
I am glad to have backups 
but these crashes still meant lost work and time.
I noticed all gui parameters seems to be in the gui.pde file so I am not sure what this gui.ser.x file is about.
Is there a way to rebuild this gui.ser.4.3 file from the sketch ?
1 Like
The short answer is No
No one has reported any similar problems when using GUI Builder so it might be a challenge to find the problem.
What were you trying to do when the program hangs?
Can you copy and paste the full exception message here?
The gui.ser.4.3 file holds the GUI design data is an object serialised format which is uneditable. The 4.3 indicates that the GUI was created with version 4.3.? of GUI Builder. It is created everytime the design window looses focus and read when GUI Builder is opened for a particular sketch.
Processing is a complex environment so I recommend that only have one sketch open at a time when using GUI Builder.
1 Like
@quark, thanks for the quick reply. These crashes (happened twice here) happened when I was doing a lot of work in the G4P tool. The project I am working on has two windows and the crash happened when I started modifying a control on the second window and then clicked on the tab for the main window. Suddenly I was unable to switch back to the second window. No restart, reload etc. helped. The error message pointed to an exception that -2 is not allowed as a position value. However I checked gui.pde and all position settings looked right. It was not too bad as I could restore an older version of my project and re-create the lost controls.
And I did have problems with negative size values before (without crashes), where it is possible to drag the corners of a control (textfield, label) in a way that it tilts upside down with negative size values created.
Although my computer is fairly powerful (8 core i7) and 16Gb RAM, I wonder if race conditions related to delayed writing from cache to disk are causing these problems. I sometimes get āconcurrent modificationā exceptions when I try to start the sketch right after I closed the G4P designer window. Waiting a couple of seconds between closing the tool and launching the sketch solves this.
Would it be possible to serialize object data in a readable/editable text format like JSON instead of the current format ?
1 Like
Just to add: I am using the latest Processing with the latest G4P on Ubuntu 18.04 64bit.
I will try any reproduce the problem based on what you said here.
When the deign window loses focus or is closed it creates the gui.ser file to save your G4P design THENit generates the source code in the gui tab. This may take a few moments but even sp should not cause concurrent access exceptions. I have never experienced them.
Using JSON or XML to store the current design is a better alternative to serialisation but I donāt have the time to do it - we are talking several months and I have other projects on the go.
1 Like
I think I found the culprit for the problem: I am using my Nextcloud server to create live backups. What seems to happen is that the first file modification triggers the Nextcloud client syncing. If a second modification happens in rapid succession the file is locked by Nextcloud and - ouch !
I will probably move my code to use a local git repo that pushes to Nextcloud in order to avoid this problem. I have done this before - itās just a bit more inconvenient.
Would it be possible to have an option in the G4P design tool to disable the automatic saving / code modification and to only do this on demand by pressing a āsaveā button for example ?
Another feature that might be easier to implement than JSON etc. might be to save the serialization to a temporary file and then copy over to the actual file once the code has been modified. This would keep the old serialization file and only updates it once the transaction is complete.
1 Like
It should be possible but I am not keen on the idea, it would be so easy for the user to forget and lose all the design data when closing the associated sketch.
This is not realistic because you canāt convert a JSON or XML file to a Java serialized file. If I was to use JSON or XML then it would replace the current method. This would be ideal because it would solve another problem associated with G4PTool and backward compatibility but you would still have the auto-update and Nextcloud issue.
As I said before