Re: SwingWorker.execute() does nothing

On Thu, 09 Oct 2008 02:20:23 -0700, Ben Phillips <b.phillips@xxxxxxxxxxxxxxxxx> wrote:

No, wait a minute, you were not supposed to reply.

Says who? You? You don't have the authority to tell me what to do.

Please stop doing so. This thread is closed.

That doesn't make any more sense when you write it than when "zerg" wrote it. And you wonder why I believe you are the same person.

[...]
Oh, really? Then name the person I supposedly disrespected.

The person who designed the part of Java you're complaining about. Who you called a "bonehead" and an "idiot".

[...]
You could have said "I don't think that guy, whoever he is, was actually a bonehead" and left it at that. But you didn't. You also opened up on me with both barrels, which is not good. Not good at all.

What a thin skin you have, especially considering your willingness to insult anyone and everyone who dares disagree with you. "Both barrels"? Give me a break. I was using a pea-shooter at most.

[...]
Pointless, off-topic, and a waste of bandwidth. I wonder if this behavior violates your service providers' terms of service? Ditto not respecting a followup-to header

lol! Please. I encourage you. Write email to both my news provider _and_ yours, documenting what's transpired in this thread (feel free to do so in your own words using your own perception). Otherwise, leave off the "you violated the terms of service" crap.

[...]
Why are you still posting to this thread?

I am defending myself and explaining myself.

Ah. So in spite of having said you were, you are not in fact "ready to move on".

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

Which, in turn, stops events from being posted.

No. _Only_ user input events. Those are not the only events dispatched from the event dispatch loop. Repaint events, run() calls for invokeAndWait() and invokeLater() calls, etc. these all still continue to happen.

[...]
Some exemption has to be made for paint events no matter which method is used, I suppose.

No exemption is necessary. The paint events aren't blocked in the first place, and the modal dialog still has a working event dispatch loop.

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

That is not a crime, whatever you may think. Please stop prosecuting me for this "crime". Or perhaps I should say PERsecuting me?

As if I needed more proof that you have a persecution complex, you come right out and _say_ it.

In any case, stating that you're inexperienced isn't a criticism at all. It's simply an observation explaining your behavior, both respect to your failure to debug the problem properly and your failure to infer the actual behavior correctly.

[...]
The static methods are simply convenience methods (and are documented as such). There is no "something special"

And how, exactly, is this going to be apparent to someone who hasn't extensively studied Swing's internals and Sun's source code?

I don't think it's too much to ask of someone to read at least the doc page for the class they are using. From http://java.sun.com/javase/6/docs/api/javax/swing/JOptionPane.html :

almost all uses of this class are one-line calls
to one of the static showXxxDialog methods shown below:

[...]

Each of these methods also comes in a showInternalXXX
flavor, which uses an internal frame to hold the dialog
box (see JInternalFrame). Multiple convenience methods
have also been defined -- overloaded versions of the
basic methods that use different parameter lists.

Eh, oh mighty Judge? Your expectations are ridiculously high,

If you can find one person who regularly posts in this newsgroup, other than your alternate personalities ("zerg", "Twisted", etc.), who will agree with your claim that expecting someone to read the documentation page for the class being discussed and used is a "ridiculously high" expectation, I will apologize for accusing you of failing to perform due diligence in researching this problem.

I doubt you can.

[...]
nor does it make any sense that the _only_ way to prompt the user for
input would be to go through the static methods.

Did I say anything about it being the only way?

Sure. By claiming that your incorrect inference was the only logical conclusion, you did. If you had accepted there were other ways, you wouldn't have come to that conclusion.

[blah blah blah ]

It has everything to do with YOU being ready to move on. Or not, as the case may be.

Each of us may or may not post according to each of our being "ready to move on". The difference here is that you've stated that you are in fact ready to move on, and yet cannot help yourself from replying. I've made no such claim, and I'm more than happy to keep replying as the mood suits me.

If you really want the thread to end, you need do nothing more than just not reply. If you really were "ready to move on", you would feel no need to reply. You keep replying. So obviously you are not "ready to move on", and you don't really want the thread to end.

It's the obvious logical conclusion.

Pete
.