Re: SwingWorker.execute() does nothing

Peter Duniho wrote something when he was supposed to let this drop:
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,

So, it's okay to be disrespectful to people as long as you do it behind their back?

I wasn't. I didn't name any particular names. Unlike you.

Too bad. I don't buy that logic. Disrespectful is disrespectful, and whether the person you were disrespecting was here to read your post or not, your comment was still "unconstructive material".

So, in your estimation, two wrongs make a right?

Don't tell other people to

Don't tell other people what to do. You have no authority here.

Java works just like any other API and its behavior isn't surprising at all.

If its behavior "isn't surprising at all", then this newsgroup would not contain any posts expressing surprise about it, now, would it?

Please do not post unconstructive material, particularly personal attacks.

Ah. I'm starting to see the light. Not only would you get along famously with "zerg/Twisted/Paul/etc.", you _are_ one of the personalities of that person.

I don't know what you're talking about, but it sounds like paranoid ravings of some kind.

This is comp.lang.java.programmer, not alt.conspiracy. Please try to stick to the topic defined in this newsgroup's charter.

I was not, however, dealing with the behavior of a Dialog, at least not apparently.

[personal attacks]

Enough. This is pointless and unproductive. The original problem has been solved. Why are you still posting to this thread? What do you want from me? Whatever it is, obviously I'm not giving it to you and obviously I'm not about to, either, so you may as well just give up and get on with your life.

Had you bothered to step through the code in the debugger

Debugger isn't very convenient to use with this IDE.

[more personal attacks]

See above. Please go away.

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.

[more personal attacks]

Since you obviously have nothing more to say here in the way of constructive and helpful, problem-solving things, please do shut up.

I do not understand why you and other people are arguing with me, and even attacking me personally.

[more personal attacks]

And this time you went so far as to call me a liar.

That's it. I've had enough out of you. Welcome to my ***-list.

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.

[more personal attacks]

See above.

Whether I've replied to other posts of yours is irrelevant, though since I suspect [rest of conspiracy theory deleted]

Have you seen a psychiatrist lately?

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.

All due respect, [personal attacks]

In the future, please do not lie by typing the phrase "all due respect" when you are being highly disrespectful and rude. It is extremely dishonest.

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.

Correct. And in that situation, how do you think the code is blocked until the dialog is dismissed?

What are you talking about? The assumption would be that it returns to the event dispatch loop, but since no more events are posted to the main UI, none of your other event-handling code gets called.

Especially since the UI doesn't hang and stop repainting itself, which is what one would expect if it didn't return to the event dispatch loop.

* 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).

Correct. And in that situation, how do you think the code is blocked until the dialog is dismissed?

It could be attributed to something special in the static method.

* To present a more complex, interactive UI, often in response to a menu item selection. Typically right before a method returns.

Correct. And in that situation, how do you think the code is blocked until the dialog is dismissed?

What are you talking about? The assumption would be that it returns to the event dispatch loop, but since no more events are posted to the main UI, none of your other event-handling code gets called.

Especially since the UI doesn't hang and stop repainting itself, which is what one would expect if it didn't return to the event dispatch loop.

* 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().

[another false accusation of dishonesty]

Go to hell.

How is it that you can be aware of all these other use cases for Dialog, with the implied behavior of the setVisible() method

THERE IS NO IMPLIED BEHAVIOR OF THE SETVISIBLE() METHOD!!!

SEE ABOVE, YOU JERK.

Well, except that in the other three cases, if setVisible(true) didn't block, everyone would notice a completely different problem: showing a modal dialog failing to block the calling code.

That isn't a problem unless it's returning a value to the calling code. The JOptionPane static methods do block and return a value to the calling code.

I will repeat myself one more time for clarity, since you seem to be somewhat thick-headed:

The coder new to Swing observes these things. First, sometimes they show an error dialog in an event handling method that generally immediately returns into the event loop. The dialog appears, the user clicks OK, life goes on. In particular, the OK button works, suggesting that the event loop was returned to.

There is nothing here to indicate that the method didn't return immediately after the dialog appeared, and circumstantial evidence that it did, namely the OK button works (and everything else, including the parent window, repaints itself properly when uncovered). That no other event handling code is called while the dialog is visible is no surprise, since the only event that can be generated while the dialog is visible is a click on the dialog's own OK button, and the user hasn't registered a listener on it -- it's supplied by JOptionPane. Or if they rolled their own, and registered a listener on it that closes the dialog, this listener does get called and does close the dialog.

Second, sometimes they show a complex dialog UI, such as a preferences dialog with tabbed option panes and other complexity. Some menu item action event listener shows this right before the method's close brace. The event loop shows no signs of not continuing, since the UI remains able to paint itself and the dialog's UI components generate events.

There is nothing here to indicate that the method didn't return immediately after the dialog appeared, and circumstantial evidence that it did. That the main UI generates no event handler calls is unsurprising, since the main UI won't receive any user input events while the modal dialog is displayed.

Lastly, sometimes they use a JOptionPane static method that returns a value. This does block, but obviously the static method could be doing something special to wait for there to be a value to return. The coder's initial mental model of this behavior is probably along the lines of "setVisible(true); someObject.wait(); return someObject.getSomeValue();". That may not be correct, but it is what they will initially think, given no reason to think otherwise. As for the rest of the UI continuing to update and repaint, that gets brushed off as "magic". The API designers obviously have the ability to do something special to special-case these, so the coder shrugs and moves on.

Then he codes something simple and seemingly obvious: show a progress or wait-message dialog and spawn a worker thread. And everything screeches to a halt in much the way it hadn't done on all of the previous occasions, except for those "special" native API methods, all of which had involved calling a method that showed a specialized dialog AND RETURNED A VALUE.

And he posts here.

And then you get on his case for not either reading large, not obviously relevant parts of the documentation or having some sort of special insight into the API design. You even get on his case for not having much experience programming in other, non-Java GUI systems, even though a) such are not relevant or a prerequisite for being treated with a basic level of respect, only being a member of the species Homo sapiens is; b) such are not relevant or a prerequisite for being a Java programmer; and c) your guess is wrong anyway, and it just so happens that his previous experience has been with GUI systems where showing a modal dialog does not block the running code, only the generation of UI events from the parent frame, and it's common to have code that shows a modal dialog with a listener attached to it, returns, and the listener handles whatever the input was -- the default system-provided one being fine and dandy for the case of just an OK button on a message box.

Heck, you even got on my case for, to judge by several somewhat incoherent and difficult to interpret remarks of yours, being part of some conspiracy or another that no doubt only exists in your own mind.

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.

It's not a Swing concurrency issue.

Sure it is. The Swing concurrency model presented in that part of the tutorial is that there is a) an event dispatch thread and b) worker and other threads, and all Swing actions should occur on the former. From this, the coder logically concludes that myDialog.setVisible(true) cannot possibly block because if it did, a) calling it on the EDT would lock the application up solid and in particular the user couldn't respond to the dialog because the event handlers for its buttons would never run, whereas b) calling it off the EDT would cause race conditions and other thread-safety problems.

The Swing concurrency pages at the tutorial clearly imply that the behavior is different from the actual behavior, and it seems to be the case that there are actually multiple event dispatch loops, only one of which is active at a time (either multiple threads, or recursively entered inside of a blocking method call).

The Swing concurrency page, in other words, is indeed a source of confusion on this point. It should be far more clear about what really goes on. As it stands, it strongly implies (though does not really state) that any method called in an event handler and failing to return hangs the UI. Since things like

public void actionPerformed(ActionEvent e) {
if (e.getSource() == somethingOrOther) {
...
if (e.getSource() == preferencesMenuItem) {
myPreferencesDialog.setVisible(true);
return;
}
if (e.getSource() == somethingElse) {
...
}

don't result in "I start it up to test it, click File, click Preferences, and the dialog appears but the UI freezes up", the coder concludes from this and the "a blocking method call in an event handler hangs the UI" message of Swing's tutorials, that the "setVisible(true)" did not block.

That myMainFrame.setVisible(true) did not block also suggests this. That setProperty(value) methods in general don't tend to block also suggests this.

EVERY LINE OF EVIDENCE, and most of the tutorial documentation, point to the (erroneous, it seems) conclusion that it doesn't block, BECAUSE THE API DESIGNERS DID SOMETHING STRANGE somewhere in that particular method call and the documentation writers didn't make it clear in various places where it seems sensible to mention it.

As one of the other posters noted, "they cheat", in reference to avoiding a UI hang when one of the static, value-returning JOptionPane methods is called.

There's no reason for the Swing concurrency section to mention it.

See above.

Your problems are threefold:
1. You think like a designer, and as someone with years of experience and familiarity with the API. You do not therefore think like someone using the API that does not have extensive experience with it yet.
2. You also have an attitude problem. People either are as expert as you are, AND agree with you, or else they are morons. In particular, anybody who does not just nod and move on in response to anything you say, even such unwarranted, rude, and off-topic things as personal criticisms, is clearly a fool.
3. You appear to believe some strange conspiracy theory or another.

Until you improve your attitude, those problems will not go away. And until then, I will not respond to anything else you have to say except to answer specific questions, defend myself against specific and erroneous public criticisms, or clarify my own previous writing.

There was nothing that would clue me in in the method that appeared to be causing trouble, SwingWorker.execute().

Nothing? Well, not when you don't bother to debug your code, no.

I DID bother to. As I described originally, I put debugging prints in both doInBackground() and done() and determined that neither was being called. It did not occur to be that execute() was not even being reached, because I had

foo.setVisible(true);
bar.execute();
return;

and foo.setVisible(true) was obviously executing, since foo actually became visible, and return was "obviously" executing and returning to the event loop, since the UI did not freeze completely and cease even repainting itself when uncovered, and no exception trace had appeared in the console to indicate that it had gotten out of the method other than by reaching the return statement. Given this, why would I ever suspect that it might be "skipping over" the bar.execute() line? After all, "the UI still repaints itself" was, according to the Swing tutorial, synonymous with "my event handler returned or threw an exception", the lack of a stack trace in the console eliminated the latter, and the only return was right after bar.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.

Really? And yet, you saw the need to reply to my post?

I saw the need to defend myself against your spurious and completely uncalled-for attempt at public character assassination, yes.

That doesn't seem like someone who's "ready to move on".

You're the one making this personal. It seems that you're the one with some sort of an ax to grind.

.