Re: SwingWorker.execute() does nothing



On Wed, 08 Oct 2008 17:47:25 -0700, Ben Phillips <b.phillips@xxxxxxxxxxxxxxxxx> wrote:

Really? What idiot made that boneheaded design decision --

[...]

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

Please do not post unconstructive material, particularly personal attacks.

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

You're wrong on other counts as well, but when it comes to ad hominem, you're the guiltiest party in this thread.

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.

You and "zerg/Twisted/Paul/etc." should get along famously. You both have this very strong, unshakable impression that everything should be documented exactly where you look, instead of where you _should_ have looked.

Obviously, documentation of a "gotcha" is not very useful if it is not located where the user is most likely to look for it.

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.

This issue has practically nothing to do with SwingWorker. SwingWorker is involved only because _you_ brought it into the picture by using the Dialog instance in the same section code as the SwingWorker. You would have had the exact same problem with _any_ code you'd written after calling the setVisible() method.

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.

That makes no sense. 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". After all, Dialogs are presented to the user in a practically infinite variety of situations.

No, what makes more sense is that programmers simply should be expected to read the documentation related to the methods they are calling.

Pete
.



Relevant Pages

  • RE: MS Security update 891781 - Microsoft Security Bulletin MS05-0
    ... There is virtually no documentation on this from Microsoft, ... and moved it to it's calling page, ... I know it's not as pretty, but it's a workaround, ... var properties = new Object; ...
    (microsoft.public.windowsxp.security_admin)
  • Re: New Orleans Vote
    ... Speaking of "documentation", the NEXT time you document what you claim ... support your skewed views - will be the FIRST time. ... what you refer to as my "grade school name calling" was nothing ...
    (alt.smokers.cigars)
  • Re: Where to find options for add_command?
    ... change color, font, size, background, for the label of Open File. ... Menu class or factory function that you are calling, ... to search the web to find the documentation for you. ... If you tell yourself the name of the module or package that contains ...
    (comp.lang.python)
  • Re: Swing didnt Swing - Help!!
    ... directory structure that goes with them, ... all covered in Jeff's documentation, ... There are also event log entries that will help identify if there's an issue ... Calling an illegal alien an "undocumented worker" is like calling a ...
    (microsoft.public.windows.server.sbs)