Re: SwingWorker.execute() does nothing

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.

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.

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

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

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

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?

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.

What do you want from me?

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.

Had you bothered to step through the code in the debugger

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

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.

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.

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

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

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

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

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.

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

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.

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

[noise]

Please go away.

SEE ABOVE, YOU JERK.

[noise]

Please go away.

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.

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.

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.

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.

It's not a Swing concurrency issue.

Sure it is.

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.

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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.

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?

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