I’ve been building my swing URCap and have run into a curious problem.
When I make changes to my Cap program node, polyscope does not allow me to Save the program. I know that the data model is being changed, because if I change another node’s data (say a wait node), then save it, the URscript for my cap node is generated correctly.
I’ve looked through the samples and cannot find any major differences in methodology in the functions called when a value is changed. However I am unsure where specifically to look because I’m not sure what in java/polyscope exactly triggers the ability to save. I’m using numerical labeled input fields for my node.
I seem to be having the inverse problem, I can make changes to the same type of input fields in my installation node of the URcap and that allows me to save. I basically copy and pasted that code for my program node input fields. I have a type selection combo box field in my program node, and if I change that I can save. It seems to be limited to just typed input fields in the program node. Here is a snipped of the code (I think) that may be involved.
@ianc
What changes exactly are not enabling the save program button? in testing the URCap im currently writing, i found that the majority of JavaSwing objects had no problem enabling the save button as a result of changing the data model. JComboBox, JCheckBox and JSlider I found worked fine. However, when saving values from a JTextField that called a <Double> keyboard to the data model, the save button wasn’t enabled. Values saved from an <Integer> keyboard however, I found to work just fine.
Someone found this issue previously in this post: Save Program greyed out - UndoRedo
This issue has also been reported as a bug: Double keyboards not covered by undo/redo
EDIT: Whilst the <Double> keyboard didn’t enable the save button, when changing other things that did enable saving, the values set by the <Double> keyboard were still saved.
@sam.verity-hilton Yes its a double input keyboard so I guess I stumbled onto the same bug. The work around I found was to convert the double to a string then write that string to dummy variable at the same time, thus forcing the save to enable.
@ianc1
Nice workaround. This does indeed allow the save button to be enabled when making the change (which suggests that the bug isnt in the double keyboard, but rather in saving double values to the DataModel?). But the same bug means that the undo/redo buttons don’t cover changes made in double text fields, and with this work around, the undo/redo buttons still don’t cover the changes.
