Hi Landon, I must admit the validation procedure of the dialog is a bit unusual.
MultiInputDialog adds a listener to the OKCancelPanel (in MultiInputDialog.jbInit() If an action is performed on this panel , okCancelPanel_actionPerformed will check if OK button has been pressed (OKCancelPanel.wasOKPressed()). If it was pressed, MultiInputDialog.setVisible is set to false. As it is generally initialized as a modal dialog, setting it to false will make it return (javadoc). Wonder why you need that. I think in most case, using a modal dialog and a threaded plugin is the way to go - thread avoid your UI to freeze and you can interrupt the plugin from the dialog. - modal avoid concurrent operations If you don't use threads for long running task, I think the UI can quickly freeze and become ugly If you don't use modal dialog, it will be hard to keep OJ and your dialog consistent in the case where you play with layers. Let us know what's your use case and your feedback Michaël > OK. I did some poking around the code on my lunch break today. I > couldn't find a direct mechanism in the code that indicated to me how > control was passed from the MultiInputDialog to the PlugIn after the > OK button was pressed. > > Here is my wild guess: > > The MultiInputDialog class assumes control once the setVisible method > is called. (This is a method of the JComponent Class.) From what I've > read, this now passes control of execution of the program to the event > dispatch thread. This means execution in the execute method of the > plug-in is "paused" until the OK button is pressed. Once the OK button > is pressed, execution passes out of the event dispatch thread and back > to the plug-in. So, the call to wasOkPressed isn't really polling, its > like an event listener. This confused me, because the call to > wasOkPressed doesn't look like a pause in execution when you are > staring at the source code of a plug-in. It looks like you are simply > requesting a boolean value. > > Having said that, the above statements involve a lot of guessing. The > Javadoc for JComponent.setVisible does not describe the behavior > mentioned above. > > I'm thinking a proper way to implement the desired behavior would be > to have the MultiInputDialog add itself as an action listener to the > OK and Cancel buttons. I'll note the OKCancelPanel's super class, > ButtonPanel, allows you to do this. > > What happens when I execute a plug-in that uses MultiInputDialog, and > the user attempts to execute GUI actions in the main JUMP workbench > window. That would really mess things up, unless the MultiInputDialog > class is meant to be modal only. > > Hopefully this isn't babbling, and someone with more Java programming > experience can comment. I always get a little nervous when I can't > figure out how the code works. Perhaps I'm missing something obvious. > > Landon > > > On Tue, Jun 26, 2012 at 12:13 PM, Landon Blake > <[email protected]> wrote: >> Thanks for the feedback Stefan and Michael. >> >> I don't like to use ThreadedPlugIn classes, because in my mind large >> parts of OpenJUMP are not thread safe. >> >> I'll dig into the source code for the MultiInputDialog with special >> attention to the wasOkPresesed method. It sounds like it is a polling >> method, which is interesting. In my mind you'd need to add an event >> listener from some part of your plug-in to the OK button in the >> dialog. It looks like Vivid Solutions found a way around that. >> >> I'll check it out. >> >> I look forward to working with the MultiInputDialog class. >> >> Landon >> >> P.S. - I do have Michael's doc on the MultiInputDialog class. It is >> the first place I looked. :] >> >> On Tue, Jun 26, 2012 at 12:01 PM, Michaël Michaud >> <[email protected]> wrote: >>> Hi, >>> >>> Stefan is right, >>> >>> the usual way is to collect data in the execute method (where the dialog >>> is defined >>> and shown to the user until this one click OK or cancel) and to process >>> it in the >>> run method (run only if the execute method returned true). >>> >>> I usually include all the input dialog construction in the execute method, >>> but doing it in a separate method, as suggested by Stefan, is probably a >>> good advice. >>> For me, the only difficult part in the dialog definition is to create >>> some interaction >>> between components (ex. disable one component if the selected layer is >>> not editable) >>> >>> MultiInputDialog has not changed so much, but I added a few utils (like >>> an attribute chooser) >>> and make it a bit more flexible. >>> Don't know if you checked this document >>> http://sourceforge.net/projects/jump-pilot/files/Documentation/PlugIn%20Documentation/ >>> >>> and of course see some plugin implementations in the source. >>> >>> Michaël >>>> I am not sure - but if you look at the example buffer plugin on the wiki... >>>> what would be different? >>>> >>>> maybe that you are using a threaded plugin? >>>> >>>> there are lots of plugins to look at. But as soon as you use a dialog I >>>> would say you should use "extends AbstractThreadedUiPlugIn", do your >>>> dialog stuff in "execute()" and do all your computation in the "run()" >>>> method that is automatically called after things are done in execute. >>>> See below... >>>> >>>> but maybe I miss a point here too. >>>> stefan >>>> >>>> >>>> public boolean execute(PlugInContext context) throws Exception{ >>>> //Unlike ValidatePlugIn, here we always call #initDialog >>>> because we want >>>> //to update the layer comboboxes. >>>> initDialog(context); >>>> dialog.setVisible(true); >>>> if (!dialog.wasOKPressed()) { >>>> return false; >>>> } >>>> else{ >>>> this.getDialogValues(dialog); >>>> } >>>> return true; >>>> } >>>> >>>> public void run(TaskMonitor monitor, PlugInContext context) throws >>>> Exception{ >>>> System.gc(); //flush garbage collector >>>> this.context = context; >>>> monitor.allowCancellationRequests(); >>>> //....you stuff here... >>>> } >>>> >>>> Am 26.06.12 12:47, schrieb Landon Blake: >>>>> I'm working on a plug-in for OpenJUMP. Usually I will "roll my own" >>>>> plug-in GUI, but this time the GUI was fairly simple, and I wanted to >>>>> try out Michael's improvements to the MultiInputDialog class. >>>>> >>>>> I've been looking over the API for the code, and I've bumped into a >>>>> smal challenge: >>>>> >>>>> Instead of processing the data collected in the dialog using the >>>>> AcitonPerformed event of each JTextField, I'd like to do the data >>>>> processing when all the data is present, after the OK button is >>>>> pressed. This will allow me to do some data validation. I see the >>>>> class has a "wasOkButtonPressed" method, but I don't think that is >>>>> what I need. What I really need is a way to respond to the OK button >>>>> click event. >>>>> >>>>> I could hack something, but I thought I'd ask if there is a "standard" >>>>> way to do this using the MultiInputDialog class or its ancestor >>>>> classes. I'd like to learn the "right" way to use the class because I >>>>> may prepare a little MultiInputDialog tutorial when I'm done. >>>>> >>>>> Hopefully this makes sense. I'm probably missing something obvious. >>>>> >>>>> Thanks in advance for the help. >>>>> >>>>> Landon (AKA - The Sunburned Surveyor) >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Live Security Virtual Conference >>>>> Exclusive live event will cover all the ways today's security and >>>>> threat landscape has changed and how IT managers can respond. Discussions >>>>> will include endpoint security, mobile security and the latest in malware >>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>>> _______________________________________________ >>>>> Jump-pilot-devel mailing list >>>>> [email protected] >>>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>>>> >>>> ------------------------------------------------------------------------------ >>>> Live Security Virtual Conference >>>> Exclusive live event will cover all the ways today's security and >>>> threat landscape has changed and how IT managers can respond. Discussions >>>> will include endpoint security, mobile security and the latest in malware >>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>> _______________________________________________ >>>> Jump-pilot-devel mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>>> >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> Jump-pilot-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Jump-pilot-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Jump-pilot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
