Re: SwingWorker.execute() does nothing
- From: Ben Phillips <b.phillips@xxxxxxxxxxxxxxxxx>
- Date: Wed, 08 Oct 2008 23:49:18 -0400
Peter Duniho wrote:
Please do not post unconstructive material, particularly personal attacks.
You would do well to follow that advise as well, being the person who started the "bonehead" theme, as well as calling the person who was involved in the design decision an "idiot".
That was not directed at a participant here in this newsgroup, and it did involve violating the principle of least surprise in designing the API. None of the other setFoo, getFoo, and the like methods block, after all, including (most of the time) setVisible.
[more personal attacks]
Please do not post unconstructive material, particularly personal attacks.
It is documented under the setVisible() method of Dialog (from which JDialog
derives) in the API docs
But that was not where I was looking. Since the problem appeared to be with SwingWorker.execute(), *that* was where I was looking.
[more personal attacks]
Please do not post unconstructive material, particularly personal attacks.
Obviously, documentation of a "gotcha" is not very useful if it is not located where the user is most likely to look for it.
When dealing with the behavior of a Dialog, I would expect the rational user to be most likely to look in the documentation for the Dialog class.
I was not, however, dealing with the behavior of a Dialog, at least not apparently. I was dealing with the behavior of a SwingWorker, at least apparently. The dialog appeared correctly. The SwingWorker task did not appear to execute. Ergo, the SwingWorker appeared to be the source of the problem.
I do not understand why you and other people are arguing with me, and even attacking me personally. Do you take it personally around here when someone questions a design decision in Java, or suggests that the documentation could be better? That is a rather nonconstructive attitude for you to take. It is not an attitude that will help improve Java and its documentation, nor is it an attitude that will endear you to the people who ask questions here. Please check that attitude at the door from now on.
This issue has practically nothing to do with SwingWorker.
However, that was not obvious.
Perhaps a note to this effect should be in *both* places, given the likelihood that someone will be showing a modal progress dialog or other such thing during a long-running operation, and given the natural tendency to want to pop up the dialog *first* and *then* start the operation.
That makes no sense.
It does too make sense. Your attitude is what makes no sense. Especially since you've never, to my knowledge, replied to one of my posts before, and now you do so in a manner tinged with hostility, as if I'd affronted you personally in the recent past, though I know I've done no such thing.
The logical conclusion from your assertion is that every single class method in the Java API should include documentation that says "if placed after a call to Dialog.setVisible(), this method will not execute until after the user has dismissed the Dialog".
Nonsense. Only the specific case that's especially likely to trip people up, which is where they pop up a progress dialog and then launch a SwingWorker to do a background task that will report progress.
After all, Dialogs are presented to the user in a practically infinite
variety of situations.
Actually, dialogs are typically presented in about four situations:
* To present a message. Usually right before a method returns or continues to propagate an exception.
* To ask a question. Typically using one of the JOptionPane static methods that obviously block, because they return a value that depends on the user's input. The assumption is that the JOptionPane method does something special. In particular it isn't just a bald setVisible(true).
* To present a more complex, interactive UI, often in response to a menu item selection. Typically right before a method returns.
* To display a wait message or a progress meter during a lengthy I/O operation, calculation, or what-not. Typically adjacent to a SwingWorker.execute().
Only in the fourth case is anyone likely to notice any problem resulting from setVisible(true) blocking. Add that the Java Tutorial makes no mention of this in the section on Swing concurrency, and it's not hard to understand how this can cause a difficult-to-diagnose problem.
No, what makes more sense is that programmers simply should be expected to read the documentation related to the methods they are calling.
There was nothing that would clue me in in the method that appeared to be causing trouble, SwingWorker.execute().
Now please drop this subject. Obviously we don't, and won't, agree on how much documentation should exist where. Continuing to belabor the issue won't accomplish anything, and your mudslinging certainly won't.
The original problem has been solved. I'm ready to move on. Are you?
.
- Follow-Ups:
- Re: SwingWorker.execute() does nothing
- From: Hendrik Maryns
- Re: SwingWorker.execute() does nothing
- From: Peter Duniho
- Re: SwingWorker.execute() does nothing
- References:
- SwingWorker.execute() does nothing
- From: Ben Phillips
- Re: SwingWorker.execute() does nothing
- From: Thomas Kellerer
- Re: SwingWorker.execute() does nothing
- From: Ben Phillips
- Re: SwingWorker.execute() does nothing
- From: Nigel Wade
- Re: SwingWorker.execute() does nothing
- From: Ben Phillips
- Re: SwingWorker.execute() does nothing
- From: Peter Duniho
- SwingWorker.execute() does nothing
- Prev by Date: Re: SwingWorker.execute() does nothing
- Next by Date: Re: SwingWorker.execute() does nothing
- Previous by thread: Re: SwingWorker.execute() does nothing
- Next by thread: Re: SwingWorker.execute() does nothing
- Index(es):
Relevant Pages
|
