Re: SwingWorker.execute() does nothing

On Wed, 08 Oct 2008 22:20:21 -0700, Ben Phillips <b.phillips@xxxxxxxxxxxxxxxxx> wrote:

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.

Of course you were.

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

You don't have to name names to be disrespectful.

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?

No. My reply was in defense of a person wronged. The defense of a person wronged _is_ a right.

Don't tell other people to

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

Hypocrite.

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?

The behavior isn't surprising, even if you yourself were surprised by it.

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

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

Sound familiar?

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?

Why are you still posting to this thread?

What do you want from me?

Nothing.

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.

The beauty of this is that I haven't stopped my life simply to respond here. So there's no "getting on" necessary. I can have my life and rebut you at the same time.

Had you bothered to step through the code in the debugger

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

Too bad. Get a different IDE or suck it up and use the debugger you've got.

Your laziness is no justification for your misplaced complaints about the documentation.

[more personal attacks]

See above. Please go away.

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

Sound familiar?

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

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

Sound familiar?

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.

Oooh...I'm worried. Is that sort of like having a bad mark on my permanent record?

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?

No. Have you?

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.

I granted you _all_ respect that was due you under the circumstances. I was being entirely truthful. But in any case:

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

Sound familiar?

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.

A modal dialog does not stop events from being posted, nor even from being processed. It simply block _user-input_ to the part of the UI underneath the modal dialog.

This is standard modal dialog behavior in all mainstream GUI APIs, including Mac OS (both pre- version 10 and post-), Windows (native API and ..NET), and yes...Java. Furthermore, the API convention in all cases is that the function call that shows the modal dialog will block until the dialog has been dismissed. Event dispatching continues to occur, just in a new dispatch loop provided by the modal dialog (that's exactly why the entire UI continues to be able to redraw itself as needed).

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.

Only if one was inexperienced and didn't realize that the function showing the modal dialog not only blocks, it sets up a whole event dispatch loop to ensure that messages continue to be delivered as necessary.

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

The static methods are simply convenience methods (and are documented as such). There is no "something special", nor does it make any sense that the _only_ way to prompt the user for input would be to go through the static methods.

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

It's not true that "no more events are posted to the main UI". The only thing that's blocked is actual user interaction. The main UI continues to get whatever events may still happen (so, basically everything but mouse clicks and keyboard input).

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.

Only if one was inexperienced and didn't realize that the function showing the modal dialog not only blocks, it sets up a whole event dispatch loop to ensure that messages continue to be delivered as necessary.

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

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

Sound familiar?

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!!!

Of course there is. Furthermore, there is _documented_ behavior that matches exactly the implied behavior.

SEE ABOVE, YOU JERK.

Hypocrite.

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.

Sure, it is. By convention, a modal dialog _blocks_ whatever thread initiated it. You are correct that in situations where the modal dialog isn't returning input, there's not necessarily any specific need for it to do so. But that's how modal dialogs _always_ work.

The JOptionPane static methods do block and return a value to the calling code.

setVisible(true) always blocks too, for modal dialogs.

I will repeat myself one more time for clarity,

You can repeat yourself until you're blue in the face. That doesn't change the fact that what needs fixing here is your understanding of modal dialogs.

since you seem to be somewhat thick-headed:

Hypocrite.

[blah blah blah]

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.

Absolutely wrong. I got on your case for first making unfounded insulting remarks about the designer of the Dialog class in Java, and then criticizing Nigel for making statements no worse than those you'd already made.

You also misunderstand the technicalities behind modal dialogs, and it's true that I've tried to correct those misunderstandings. But I've never gotten on your case about those misunderstandings. I've even allowed as to how they are understandable misunderstandings and nothing to be ashamed of.

It's only your hypocritical name-calling that I'm on your case about. Well, that and your hypocritical ordering people about.

It's not a Swing concurrency issue.

Sure it is.

No, it's not.

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.

None of which has anything to do with modal dialogs.

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 only reason "the coder" logically concluded that is because "the coder" started with false assumptions.

A bright coder would simply recognize the mistake and move on. But a belligerent one decides that they have to blame someone else, calling them names in the process, and arguing senselessly that the documentation is flawed.

The Swing concurrency pages at the tutorial clearly imply that the behavior is different from the actual behavior,

The Swing concurrency pages make no implication whatsoever about the behavior of modal dialogs.

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

Except that the documentation specifically states that calling setVisible(true) on a modal dialog _does_ block. Why infer from unrelated documentation when you can _know_ based on reading the actual documentation.

By the way, setVisible(true) for a modal dialog is probably the most common exception to your proposed rule by far, but I doubt it's the only one. There's nothing in Java that stipulates that "setProperty(value) methods in general don't block", and your use of the word "tend" even reinforces this. Don't assume something that the API doesn't actually say is required.

EVERY LINE OF EVIDENCE, and most of the tutorial documentation,

"EVERY"? Hardly. The two most direct lines of evidence -- the debugger, and the documentation for Dialog.setVisible() -- contradict your erroneous conclusion.

[...]
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.

I suppose one might consider it cheating. Nevertheless, it's a completely standard way of dealing with modal dialogs.

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.

No. I understand where you went wrong. YOUR problem is that you insist you had no part to play in your mistake, when that is patently false. Lots of people get it right, the first time, without nearly the drama you've engaged in.

2. You also have an attitude problem. People either are as expert as you are, AND agree with you, or else they are morons.

No. In fact, most people I deal with are not morons. Consider yourself a rarity, if you like.

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.

That's not at all the metric by which I judge fools. I judge you a fool because you cannot accept responsibility for your own mistake. Can't you admit that you're even a _little_ bit to blame for not understanding what the setVisible(true) call does in this case?

3. You appear to believe some strange conspiracy theory or another.

A conspiracy requires more than one person. My theory is decidedly and pointedly _not_ about more than one person.

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.

Yes, like "zerg/Twisted/Paul/etc.", you have a pathological need to respond to perceive insults, real or otherwise. That's on top of all the other similarities (such as blaming the documentation and API design for one's own mistakes). And you wonder why I think you're the same person.

For what it's worth, I accept that you yourself may not realize you're the same person. It's not unheard of.

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.

No, you didn't. Had you actually debugged your code, by stepping through it in a _debugger_, you would have seen exactly what was going on.

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

No doubt you say that need. See above.

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.

What does that have to do with you being ready to move on?

Pete
.