SwingWorker.execute() does nothing

[Ben Phillips]

I've got a strange app hang. A particular button click pops up a modal
"Please Wait" dialog, then constructs a SwingWorker implementation and
calls execute() on it. The done() method removes the dialog.

Nothing happens as a result of execute(), and as a result the dialog
never goes away and the app is hung.

This is a really strange one, because nothing in the API docs or
tutorial gives any hint as to what the problem could be.

My done() method calls get(), so I thought it could be hanging there
(though it really shouldn't, since done() shouldn't be called until
it's, well, done).

But I put a debugging System.out.println() in doInBackground() and it
never printed its message.

The worker being executed is definitely of the same class as contains my
overridden doInBackground() and done() methods.

doInBackground() has the println as its first thing.

done() hides that dialog before calling get() so even if somehow only
done() was getting called, and get() hanging as a result, the modal
dialog should have disappeared. It didn't.

In short, neither doInBackground() nor done() is being called.

Both of my implementations have @Override tags and there are no compiler
errors, so it's not the case that I'm accidentally failing to override
and it's actually running do-nothing superclass implementations of those
methods.

The SwingWorker subclass instance is a fresh one. The code is FooWorker
worker = new FooWorker(argument); worker.execute();

Put simply, SwingWorker.execute() appears to be doing nothing.

What could the problem be?

The javadocs for execute() say:

Schedules this SwingWorker for execution on a worker thread. There
are a number of worker threads available. In the event all worker
threads are busy handling other SwingWorkers this SwingWorker is
placed in a waiting queue.

It seems to be a bug is the sole SwingWorker can get put on a waiting
queue and never run. Or is an app that uses SwingWorker supposed to do
something to set the size of the thread pool larger than zero before any
of this stuff will work correctly?

On a side note, JFrame.setLocationRelativeTo(null) is supposed to center
the frame; it seems to center the upper left corner. Is there an easy
way to center the frame? JDialog.setLocationRelativeTo(theDialogOwner)
also doesn't seem to center appropriately.

 

[Mark Space]

Put simply, SwingWorker.execute() appears to be doing nothing.

Dunno, could you post an SSCCE? I don't have much experience with
SwingWorker but I'll take a poke at it if you can post a working example.

On a side note, JFrame.setLocationRelativeTo(null) is supposed to center

This definitely works fine for me. Dead smack in the middle of the
screen, every time. The upper left corner is where stuff goes when you
don't call setLocationRelativeTo(null). Are you sure you're calling
this correctly? SSCCE?

 

[Stefan Rybacki]

I've got a strange app hang. A particular button click pops up a modal
"Please Wait" dialog, then constructs a SwingWorker implementation and
calls execute() on it. The done() method removes the dialog.

Nothing happens as a result of execute(), and as a result the dialog
never goes away and the app is hung.
...

SSCCE? My bet, you don't call SwingWorker.execute().

On a side note, JFrame.setLocationRelativeTo(null) is supposed to center
the frame; it seems to center the upper left corner. Is there an easy
way to center the frame? JDialog.setLocationRelativeTo(theDialogOwner)
also doesn't seem to center appropriately.

works like a charm over here.

Stefan

 

[Thomas Kellerer]

Ben Phillips, 08.10.2008 08:45:

I've got a strange app hang. A particular button click pops up a modal
"Please Wait" dialog, then constructs a SwingWorker implementation and
calls execute() on it. The done() method removes the dialog.

When you call setVisible(true) on a modal dialog, your code will stop until the dialog is closed. So if you call SwingWorker.execute() after setVisible(true) the execute() will not be called until the dialog is closed.

Thomas

 

[Ben Phillips]

This definitely works fine for me. Dead smack in the middle of the
screen, every time. The upper left corner is where stuff goes when you
don't call setLocationRelativeTo(null). Are you sure you're calling
this correctly? SSCCE?

No, it's the upper left corner of the JFrame that ends up centered on
the screen, rather than the JFrame ending up in the upper left corner of
the screen.

 

[Ben Phillips]

Ben Phillips, 08.10.2008 08:45:
When you call setVisible(true) on a modal dialog, your code will stop
until the dialog is closed. So if you call SwingWorker.execute() after
setVisible(true) the execute() will not be called until the dialog is
closed.

Really? What idiot made that boneheaded design decision -- and,
moreover, didn't document it anywhere?

I'll see if simply swapping the setVisible(true) to after the execute()
fixes things. I definitely don't want the UI to receive input events
while this work is going on, but I don't want it to hang (not paint
properly) either, and eventually I might want to put a working Cancel
button on the "Please Wait" dialog too. (Were it not for those
considerations, I'd just have the work done on the EDT and the heck with
it!)

 

[Thomas Kellerer]

Ben Phillips, 08.10.2008 10:48:

Really? What idiot made that boneheaded design decision -- and,
moreover, didn't document it anywhere?

Well it makes kind of sense.

Usually the modal dialog requests user input ("Do you really want to delete that?"), and the program will normally want to wait for the "result" of that dialog.

I'll see if simply swapping the setVisible(true) to after the execute()
fixes things. I definitely don't want the UI to receive input events
while this work is going on, but I don't want it to hang (not paint
properly) either, and eventually I might want to put a working Cancel
button on the "Please Wait" dialog too. (Were it not for those
considerations, I'd just have the work done on the EDT and the heck with
it!)

Yes. Been there as well

The way I have done this, was to spawn a new thread to open the modal Dialog, thus my "worker" code continued. I used EventQueue.invokeLater() inside the Thread's run() method to make sure the Dialog is realized inside the EDT. My modal dialog also has a Cancel button, and it works nicely.

I have no idea if that is a "supported" way to open a modal dialog in a non-blocking way but it seems to work without problems on several platforms and JDK versions.

Thomas

 

[Ben Phillips]

Ben Phillips, 08.10.2008 10:48:

Well it makes kind of sense.
Usually the modal dialog requests user input ("Do you really want to
delete that?"), and the program will normally want to wait for the
"result" of that dialog.

So it's applying the JOptionPane "cheat" to arbitrary modal dialogs,
including ones it's never heard of before (novel JDialog subclasses, or
vanilla JDialogs controlled from another class).

I guess it sort of makes sense. But not documenting this at least for
SwingWorker.execute() seems boneheaded. Popping up a modal dialog box
saying "Please Wait" or similarly while a lengthy job is done has got to
be a very common usage scenario, and someone not warned of this gotcha
has a 50/50 chance of putting the dialog show before the execute.

Yes. Been there as well

The way I have done this, was to spawn a new thread to open the modal
Dialog, thus my "worker" code continued. I used EventQueue.invokeLater()
inside the Thread's run() method to make sure the Dialog is realized
inside the EDT. My modal dialog also has a Cancel button, and it works
nicely.

I have no idea if that is a "supported" way to open a modal dialog in a
non-blocking way but it seems to work without problems on several
platforms and JDK versions.
Thomas

I swapped the dialog show and the execute, and it works perfectly. The
dialog even shows some progress information (a counter rather than a
bar, since the job size is unknown in advance), and this updates nicely.
(SwingUtilities.invokeLater is used, of course.)

Now my only remaining problems are the
AffineTransformOp-turning-images-blue one, the
populate-an-editable-combobox's-text-field-with-code one, and the
setLocationRelativeTo(foo)-puts-the-upper-left-corner-of-the-frame-
where-the-docs-say-it-puts-the-center one.

 

[Nigel Wade]

Really? What idiot made that boneheaded design decision --

What do you mean, boneheaded? It's what modal Dialogs do.

What /is/ boneheaded is using a component and assuming you know what it does and
how it works. Then, when you find out your assumptions were wrong, blaming the
component for not working how you expected.

and,
moreover, didn't document it anywhere?

It is documented under the setVisible() method of Dialog (from which JDialog
derives) in the API docs, where it says:

Notes for modal dialogs.

* setVisible(true): If the dialog is not already visible, this call will not
return until the dialog is hidden by calling setVisible(false) or dispose.

 

[Mark Space]

No, it's the upper left corner of the JFrame that ends up centered on
the screen, rather than the JFrame ending up in the upper left corner of
the screen.

Interesting.

My guess: you're calling setLocationRelativeTo() before the window has
the correct size. Add all the components, call pack(), then call
setLocationRelativeTo().

 

[Lew]

It is documented under the setVisible() method of Dialog (from which JDialog
derives) in the API docs, where it says:

 Notes for modal dialogs.

    * setVisible(true): If the dialog is not already visible, this call will not
return until the dialog is hidden by calling setVisible(false) or dispose..

In general the Javadocs make the best first point of research for API
classes and methods. One should look there first routinely.

 

[Ben Phillips]

What do you mean, boneheaded? It's what modal Dialogs do.

It's not the behavior implied by the Swing tutorial, which says that
there is exactly one event dispatch thread.

What /is/ boneheaded is [personal attacks that are not relevant here]

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. Obviously,
documentation of a "gotcha" is not very useful if it is not located
where the user is most likely to look for it.

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.

 

[John W Kennedy]

It's not the behavior implied by the Swing tutorial, which says that
there is exactly one event dispatch thread.

Which is exactly why your mainline code stopped dead at the
setVisible(true). That's what "modal dialog" /means/; the dialog is
alive, while the code that displayed it is frozen, waiting for the
dialog to be dismissed. The execute(), therefore, was never even
reached, and has bloody nothing at all to do with it.

--
John W. Kennedy
"You can, if you wish, class all science-fiction together; but it is
about as perceptive as classing the works of Ballantyne, Conrad and W.
W. Jacobs together as the 'sea-story' and then criticizing _that_."
-- C. S. Lewis. "An Experiment in Criticism"

 

[Roedy Green]

I've got a strange app hang.

It is almost impossible to diagnose a problem without seeing any code.
Keep in mind that any work done by SwingWorker has to be done by the
swing thread. If you have it tied up doing something else or sleeping,
nothing will get done.

 

[Ben Phillips]

Which is exactly why your mainline code stopped dead at the
setVisible(true). That's what "modal dialog" /means/; the dialog is
alive, while the code that displayed it is frozen

No, "modal dialog" means that the main window will not receive UI events
while it is displayed.

The behavior you are describing is neither obvious from perusing the
Swing tutorial nor obvious from the industry-wide definition of "modal
dialog".

The execute(), therefore, was never even reached

But this was not obvious on casual inspection. The user's first
encounter with this is going to look like "execute() didn't do
anything". Indeed, did look like that.

Please stop posting to this thread now. The problem has been solved and
continuing to post here can therefore serve no useful purpose related to
the solving of that problem.

 

[Ben Phillips]

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.

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.

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.

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?

 

[Ben Phillips]

Peter Duniho wrote something when he was supposed to let this drop:

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?

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 shit-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?

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.

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.

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.

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.

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.

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

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.

 

[Ben Phillips]

No, "modal dialog" means that nothing happens from the main window while
it is displayed.

No, "modal dialog" means that the main window will not receive UI
events while it is displayed.

Not all of us learn the exact same meanings for a particular bit of
terminology. Particularly since different platforms, languages, and
vendors don't quite agree on these.

It can serve a useful purpose to some.

It's my thread, and I am no longer deriving any benefit from new posts
to it other than my own.

You talk of "the industry-wide definition", yet just about every GUI
programmer I have ever met, especially in the Java world, understood
that modal dialogs stop all action from their parent window.

Stop all new, user initiated action, yes.

See also my detailed response to Peter Someoneorother regarding how the
observed behavior of the APIs in question, in most commonplace
circumstances OTHER than showing a progress dialog before starting a
long-running task, and how the description of Swing's EDT on the
concurrency page, combine to give a misleading impression.
Unintentionally, I am sure, but they do so nonetheless.

Consider also that I was writing something that involved spawning a
worker thread and otherwise nothing particularly new or special (for
me). The docs I was checking extensively were therefore the concurrency
docs, which drilled in that the UI screeches to a halt and won't even
repaint itself if event handlers on the EDT don't return quickly. This
certainly suggests that setVisible(true) and other things I'd commonly
used in event handlers before must return quickly, especially as I'd
seen the UI wedge and not even repaint before if something I did in an
event listener took too long -- it was just such an occurrence that
prompted me to offload one particular task to a SwingWorker, in fact.

And naturally, since the UI didn't freeze it never occurred to me that
my event handler method wasn't returning, and since the execute() call
was right before the method's only return and there was no exception
trace occurring, it never occurred to me that execute() might not even
be getting reached.

Add to that that execute() was the only thing "new" that I was doing,
and that the previous statement was definitely executing, and it's not
at all surprising that my suspicions would fall on execute(). So I
posted here expecting to hear of some subtle gotcha with SwingWorker
that could cause execute() to quietly do nothing. Nothing in the docs
that seemed related to the problem hinted at what, or at any alternative
and likely explanation. Nothing in my previous experience had indicated
that setVisible(true) ever did anything but make something visible and
then return promptly to the calling method, either, as outlined in that
other post of mine.

Not one single thing that I did, or said, was unreasonable, with the
possible exception of the "bonehead" comment, and THAT was a) not
directed at anyone present here, b) not directed at anyone specifically
named, and c) out of frustration that this sort of land-mine was lurking
all-but-undocumented where nobody would be expecting to find it, as
evidenced by my looking all over the place around the SwingWorker
documentation and concurrency tutorials for a clue and finding none
there. At the time, and based on things written in the Swing tutorial
itself, I would not have expected that any method call in an event
handler could fail to return promptly without the UI hanging, with the
apparent exceptions of certain static methods of JOptionPane, for which
I even asked the question here of how to ensure the UI didn't wedge if I
called them from the EDT, since those obviously WOULD have to block to
return their return values.

Consider the possibility that your definition of "modal dialog" is not
the same as ... in the Java software industry.

Consider the possibility that my primary GUI coding experience may not
be in Java at this time.

Anyway, regardless of whether you agree or disagree, there is little
point in continuing this further. Please do not follow up.

 

[Ben Phillips]

Mirror.

Plonk.

Your little "followup-to" trick failed. Good night, Paul.

What's this? Suddenly you are babbling incoherently. Please seek help.

(Who is Paul? My name is Ben, and you claim yours is Lew. Perhaps you
meant to say Peter? That is, at least, the name of another poster in
this thread. (We also have a Stefan, a Thomas, a Nigel, a John, and a
Roedy.))

No matter. None of this is relevant or on topic here. Don't bother replying.

 

[Ben Phillips]

Peter Duniho wrote:

No, wait a minute, you were not supposed to reply. Please stop doing so.
This thread is closed. I, its author, have solved my original problem
and no longer derive any benefit from it. So you are violating the
newsgroup charter by posting to it. All such posts, after all, are
automatically off-topic and a waste of bandwidth.

Of course you were.

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

No. My reply was in defense of a person wronged.

The only person wronged here is me.

The defense of a person wronged _is_ a right.

The attack of another person is not.

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.

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

[personal attack]

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 that was used for its intended purpose,
to redirect a thread out of a newsgroup when its topic has drifted away
from that group's purpose and it's become mostly noise to that group.

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

That is a contradiction on its face.

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

Sound familiar?

I don't see the relevance. I made a polite request of you. You had
barked orders at me like you think you own the place.

Why are you still posting to this thread?

I am defending myself and explaining myself. You are doing neither.
Indeed, your primary goal seems to be to publicly diss me, rather than
either to discuss Java or to defend anybody.

Nothing.

Then please go away.

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.

You're the one who needs rebutting.

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

[personal attack]

Please go away, or post solely about Java.

[more personal attacks]

See above. Please go away.

[noise]

Please go away, or post solely about Java.

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

[noise]

Please go away, or post solely about Java.

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 shit-list.

[noise]

Please go away, or post solely about Java.

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?

[personal attack]

Please go away, or post solely about Java.

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.

[noise, including blatant lies]

Please go away, or post solely about Java.

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 mouse click seen by
that button, no ActionEvent generated by that click.

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

This model of yours has problems, particularly, a dispatch loop provided
by the modal dialog should result in the modal dialog displaying and
working properly, but the form it's covering not repainting when it's
moved, for example.

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

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? That IS the
word normally used when there is no real basis for the so-called
"prosecution", as I recall, especially when the true motivations are
personal. And, given the raft of personal attacks in your last two
"masterpieces of literature" here, it's quite clear that for some reason
this IS personal for you.

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? Eh, oh
mighty Judge? Your expectations are ridiculously high, and though you
may feel justified in "punishing" everyone who comes to your attention
here as not living up to those expectations, you really are not. In
fact, you're just a little twerp behind a keyboard somewhere who gets
off on behaving "all big and bad" on the 'net. Probably a shrimp who
can't behave that way in real life without being beaten to a pulp for
his efforts. You're a paper tiger, hissing and roaring and lashing out
thinking he's a real one. As for your ludicrously high expectations, I
don't give a shit about them, and you can write them all down on paper,
shred it, stuff it in a pipe, and smoke it.

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?

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

Which is what, paint events? It won't get resize or other events, since
the user can't resize it for the duration.

In any case, if the user put custom painting code in a component in the
main frame, and it still got called, they'd see that as evidence that
their method had not blocked, given the belief promulgated by the Swing
tutorials that if their event handler HAD blocked the UI would be wedged
thoroughly. Meanwhile, the user's mouse and keyboard input handlers not
getting called won't suggest otherwise for the reasons outlined.

Why am I even bothering to explain this again, though? It's become quite
obvious that you're either as thick as two planks or intentionally
avoiding acknowledging the truth in what I say as doing so undermines
beliefs about me that you don't feel like abandoning.

In neither case is your behavior rational and in neither case is my
explaining everything a third time likely to change it. I might as well
stop, just say "see my previous explanations", and mainly stick to
defending myself when you post a false allegation about me then.

Only if one was inexperienced

See my previous explanations. That is not a crime. Please stop
persecuting me for this supposed "crime".

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

[noise]

Please go away, or post solely about Java.

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

[noise]

Please go away.

SEE ABOVE, YOU JERK.

[noise]

Please go away.

Sure, it is.

No, it is not.

By convention, a modal dialog _blocks_ whatever thread initiated it.

By WHAT convention? Again, this "convention" exists only in your mind,
or in a subset of the industry, and either way is by no means universal.
This thread would not even exist were it otherwise.

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.

Then you no longer have any objections to what I've said. All of your
appeals have been exhausted, and denied. You may go away now.

But that's how modal dialogs _always_ work.

No, it is not. In your experience, perhaps it is, but not in general.
Not "always".

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

[nothing new or useful]

Please go away.

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.

No. Nothing about me "needs fixing". My understanding of Java's modal
dialogs has already been "fixed" and my understanding of modal dialogs
in general obviously far exceeds yours, since you seem to have
experience with only a subset of GUI systems that don't encompass the
full gamut of behaviors in that area.

since you seem to be somewhat thick-headed:

[noise]

Please go away.

[blah blah blah]

Please stop mischaracterizing what I have written about Java. Either
trim it or reply to it honestly.

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.

[personal attacks]

Please go away. Since you are clearly unwilling to restrict your subject
matter here to Java, you are a wilful repeat violator of this
newsgroup's charter. Gratuitous potshots at other group members, in
particular, have no place here, so please leave immediately.

You also misunderstand

No. I misunderstand nothing. It is you who misunderstand my explanations
of USER PERCEPTION, and of why it is the case that I did nothing wrong
and was not being unreasonable at any point here. And you misunderstand
those intentionally, I suspect.

I've even allowed as to how they are understandable misunderstandings
and nothing to be ashamed of.

You have also launched personal attacks, generally talked down to me,
written a lot of off-topic blather that was 100% gratuitous into your
posts, refused to respect requests to stop, refused to respect
Followup-To: headers to redirect your off-topic ramblings out of this
group, and refused to acknowledge that any misunderstandings that I HAD
had have long since already been corrected.

I have been trying to explain why those misunderstandings happened, why
they were not unreasonable or "wrongdoings" on my part, and how the
documentation could be improved to reduce the risk of the same thing
happening again to some other guy, but you have responded with nothing
but babblings, criticism, a steadfast refusal to listen to a word I
actually say, and in one particularly ludicrous instance, with some sort
of conspiracy theory about my being part of some group of people that
are supposedly plotting against you!

[personal attacks]

Please go away.

No, it's not.

Yes, it is, as I explained already. That you ignored my explanation does
not change the fact that I did explain.

None of which has anything to do with modal dialogs.

It has EVERYTHING to do with what happens if a method call in an event
handler blocks!!!

But there is no point in my trying to explain this to you, because you
do not WANT to understand me, or understand how this misunderstanding
actually arose. You'd prefer to believe that it arose because Ben
Phillips is a moron than that it arose because the Java documentation is
unclear on certain aspects of Swing event-handling. You have a preferred
theory and you just ignore any inconvenient facts that come along that
don't jibe with that theory. The only question is which it is that you
are steadfastly unwilling to let go of -- the notion that the
documentation is perfect, or the notion that Ben Phillips is an idiot.
Given that we've no past personal history before today, and you started
right out with a bang, I'd guess the former. Then again, your repeated
personal attacks suggest the latter. I, unlike you, will decide this on
the basis of evidence, though, rather than making a guess and then
refusing to abandon the resulting cherished theory come hell or high water.

The only reason "the coder" logically concluded that is because "the
coder" started with false assumptions.

Those assumptions came directly from Sun's Swing concurrency tutorials,
though, not from any defect in the coder or from any other source that
you might prefer to believe responsible instead.

A bright coder would simply recognize the mistake and move on.

Which I would have done, except that you a) started berating me for it,
b) did so in public (how rude!), and c) have not stopped doing so even
after I've explained why I don't deserve to be berated AND explained
that your conduct is not acceptable and violates the newsgroup's charter.

So I have to respond in my own defense as you repeatedly say and
insinuate things about me in public that simply aren't true.

But a belligerent one decides that they have to blame someone
else, calling them names in the process

That would be you, I suppose. You're the only person being belligerent
here, after all, and you feel the need to blame me and call me names.

In reality, errors tend to be caused by a complex mixture of human error
and human-factors flaws in the systems with which the humans are
interacting, for example, software tools and documentation, or aircraft
controls, or a hospital's system for storing, labeling, and retrieving
medications and tracking patient doses.

Industries, like the airline and health-care industries, that realize
this and make efforts to address human factors issues in system design
and to systematically reduce the likelihood of errors, find that the
rate of troublesome errors goes down when they do so.

Those that foster instead a culture of blame and hang a Judas goat every
time something goes wrong find that the rate of troublesome errors
remains high, despite the supposed deterrence value of harsh punishment
of those regarded as guilty of committing the errors. Part of the
problem is that blaming people and punishing them is very effective
deterrence against REPORTING errors instead of COVERING THEM UP. No
error reports, in turn, means flaws in the system that contribute to
errors go unidentified and uncorrected. So the errors continue, while
everyone walks on eggshells in fear of being suspected of screwing up.
This happens whether the punishment is death or, at the other end of the
scale, just "name and shame".

You appear to favor the culture of blame rather than the culture of
problem solving. You therefore do not belong in a software engineering
newsgroup. Please go away.

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

This is incorrect, as you would realize if you would actually read my
previous explanations.

The Swing concurrency pages imply that if you do something that takes a
long time in an event handler, the UI will freeze and not even repaint
itself. In fact, they more or less come right out and say that.

Event handlers commonly call someModalDialog.setVisible(true) without
the UI freezing in that manner.

This leads to the (apparently incorrect) conclusion that
someModalDialog.setVisible(true) returned promptly instead of taking a
long time.

This is the chain of reasoning by which one concludes that the Swing
concurrency pages imply that the behavior is different from what it
actually is.

I have suggested how the documentation could be improved regarding the
matter in question.

What have you suggested that was 1/10 as constructive?

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

Documentation not visible to someone trying to solve an apparent
threading problem, since that point has clearly still not gotten through
your thick skull.

Why infer from unrelated documentation when you can _know_ based on
reading the actual documentation.

I don't "know" ANYTHING from reading documentation that I didn't
actually read, because it didn't seem to be relevant. SwingWorker was
the new ingredient in the mix, and it smelled like a deadlock or similar
threading problem, so SwingWorker was where I went looking for answers.
As any intelligent person would have in the same circumstances.

That you refuse to acknowledge this after this many repetitions can only
be deliberate, because you simply refuse to believe at least one of: the
documentation isn't perfect, or Ben Phillips is an intelligent person.

Since your posts here are therefore clearly faith-based rather than
reason-based, you have no business continuing to post here or in any
other science-and-technical group. Please go away.

Don't assume something that the API doesn't actually
say is required.

But the API DOES say it's required that event handlers return quickly or
the UI will hang. This implies everything I have been saying about how
this misunderstanding got started. Obviously, the API docs should
clearly explain that there are exceptions to that rule, and furthermore,
should enumerate these exceptions and give details about each. One
obvious place to put this information is in the tutorial in the section
explaining the event dispatch thread and what not to do to avoid
blocking it and wedging your UI.

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

[personal attacks]

Please go away.

I suppose one might consider it cheating.

And you ask that people anticipate this "cheating" on pain of being
flamed by you? If you were proposing a punishment actually worthy of
fear, I'd report you to the goddamn Geneva Convention for human rights
violations there. But you're just a paper tiger, and if you keep posting
off-topic and inflammatory personal attacks to this newsgroup, you might
soon get declawed by your internet provider.

No. I understand

Obviously not, or you would have rescinded your negative judgments of me.

Lots of people get it right, the first time, without nearly the drama
you've engaged in.

This "drama" is entirely of your making. You made this personal. You
ranted and raved. You posted irrelevant and off-topic random blurbs,
including something that looked like some sort of conspiracy theory. I
have done nothing but discuss Java and generally conduct myself civilly
and on the newsgroup's topic, save in some of my replies to posts like
yours.

You have some nerve accusing ME of causing the "drama". It's as if you
walked up to a bunch of people placidly drinking tea at an outdoor cafe,
drew a sword, shouted "En garde!", and started waving it about wildly
and jabbing it at one of the tea-drinkers, who naturally got up, drew
his own weapon, and started parrying your thrusts, and after a few
minutes of this you then accused the tea-drinker you'd attacked of
causing the drama.

And you call ME a hypocrite?

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

[personal attacks]

Please go away.

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.

[personal attacks]

Please go away.

I am not responsible for inconsistencies and errors-by-implication in
Sun's tutorial. Neither, to the best of my knowledge, are you, so I am
at a loss as to why you seem to be taking this so personally.

I approached this from a viewpoint of trying to identify the cause of
this and determine a way to make it unlikely to happen to anyone else.

You approached this from a viewpoint of trying to assign blame. This is
clear from your focus on who is "responsible" for the problem instead of
on how similar occurrences may be prevented in future and *why* (rather
than *who*) it happened.

Your approach is unproductive, and provably so based on the past
histories of other industries (two of which I named earlier; see above).

Please stop it. It cannot accomplish any worthwhile goal and it clearly
can, and does, have the undesirable effects of a) attacking another
person's public reputation, b) wasting bandwidth, and c) lowering the
signal to noise ratio of a serious-topic newsgroup.

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

[noise]

I don't care. Whatever your theory is, it is not a theory about Java and
it therefore does not belong in this newsgroup. Save it for alt.*.

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.

[personal attacks and conspiracy theories]

See above. Please go away.

For what it's worth, [personal attack]

If anyone here needs to see a shrink it's you. Now please -- GO AWAY.

No, you didn't.

Yes, I did. I already explained in a previous post exactly what steps I
took, but it is emphatically not true that I simply ran the program, saw
a result other than I desired, and then immediately hit alt tab,
switched to Thunderbird, and posted to comp.lang.java.programmer.

And if you repeat your claim implying otherwise again, I will denounce
it as an outright lie, since I don't believe a further repetition of it
by you could possibly be a mere mistake after that mistake has been
corrected twice already. Any further repetitions can only, in other
words, be in spite of having been told the truth, and therefore will be
outright lies.

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

[noise]

Please go away.

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

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