Denoting "modified" in a SettingsEditor? Follow
As I mentioned in a separate post the other day, I'm adding unit test support to my custom language plugin. I've implemented a ModuleBasedConfiguration and a SettingsEditor for it. I'm able to create and edit my run configurations with the desired state persisting properly with one notable issue...I can't figure out how to tell the containing UI that my form contents have been modified so that the Apply button is properly enabled my implementation of applyEditorTo() called to copy the form field data to the configuration bean.
All of my other custom UIs implement UnnamedConfigurable and therefore isModified(), but that doesn't appear to be the way that SettingsEditor implementations perform dirty checking. Hopefully I'm just missing something obvious, but I'm not seeing it right now. Any helpful pointers are greatly appreciated!
Please sign in to leave a comment.
Okay, I figure this one out finally. If anyone else is interested, you need to call installWatcher() in your SettingsEditor implementation on the root component for the form (or at least for form fields that should be monitored), uninstallWatcher() in disposeEditor(), and make sure that each of your form fields fires events according to UserActivityWatcher.processComponent(Component). Most standard Swing components should be covered, but you may need to implement UserActivityProviderComponent for some custom components or adapt existing events into expected events. For example, in my case, I wanted selection changes in a CheckboxTree to mark the form as dirty, and they weren't automatically caught by the existing JTree support since those changes are presentation changes and not model changes. Hope this helps someone else!
If I correctly understood what you suggested, it's basically to emulate a user action that triggers a configuration re-evaluation.
I'm also going down the same route, by implementing a hidden checkbox that I programatically click when a dialog window is closed. However, this feels like too much of a hack to me.
The context is that there is a bit of configuration that we're getting from a facet, not from the run configuration. We're linking to the facet dialog from the run configuration, and we expect that when the user changes the facet from, e.g., an error state to an OK state, that is also reflected in the run configuration UI. However, we can't cause it to re-evaluate unless there is a "user-like" operation that triggers the correct listeners.
Calling methods that throw ConfigurationException from a lambda won't cut it, and fireEditorStateChanged() from a lambda also doesn't work, since there are no listeners in that case.
It would be great if a workaround that's less hackish existed in IJ. I can't think of anything, though.