Re: SwingWorker appropriate

I sometimes use SwingWorker in NB Platform apps. There's no rule that says
you *must* use RequestProcessor. As long as you know what you are doing of
course. In particular SwingWorker has been a better choice for me if the
background thread has some visual frontend which the user is expected to
wait for (i.e. is modal).

Example:   I have a long running download/update without which the
application is really not useful. So I execute in a SwingWorker
(background) yet I continously send feedback to a modal dialog box so that
the user can see what is going on. He can also cancel, of course, but then
I tell him that - since he cancelled - the application will exit.

In my example there's no point in using a thread pool, as is what
RequestProcessor does. With SwingWorker I just had more control so I went
for that.

For perdiodic background tasks or tasks that just needs to run when there
are available background resources, etc, I would always use
RequestProcessor.



Peter

On Thu, Jul 28, 2016 at 7:51 PM, Mario Schroeder <[email protected]>
wrote:

> Hi,
>
> I have the following use case:
>
> I want to start a long running task in a background thread when the user
> clicks on an 'ok' button of my dialog. When the process finishes succesful
> the result shall be populated via Lookup.
> But when the user clicks on cancel the tasks should be canceled too, and
> the result should not be populated, or if accidently populated simply
> removed.
>
> My scenario works fine with a SwingWorker.
>
> But I'm having trouble when I use the RequestProcess of NetBeans.
>
> My question: Is the SwingWorker appropriate for the Plattform, or should I
> continue to try my luck with the RequestProcessor?
>
> Regards
>