🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: borland.public.jbuilder.java.swing
Article #12369

Re: long jobs, repainting, and cursor mgmt

#12369
From: Matt Krevs
Date: Fri, 15 Jan 1999 00:00
65 lines
2985 bytes
I'm definitely no expert on this but here are a few ideas.

No matter how many threads you are running, there is only ever ONE 'gui'
thread.

Maybe try the following.

From your JFrame.

1. Open dialog.
2. let the user specify the criteria
3. dispose the dialog
4. control should now be with the JFrame again. Call a method within the
dialog ( it is still valid even though it has been disposed ) that will get
your criteria
5. Start a thread that performs a job. Make sure that this new thread has no
GUI elements in it.

Repeat steps 1 to 5 for each dialog.

You are correct about setCursor() because there is only 1 GUI thread ( I
think its called the event dispatching thread ).

If you ever want to do a GUI task from within another thread you need to
call swingUtilities.invokeLater() to post your task on the main thread.

William Glocker wrote in message <369E31E2.51EE54DC@bigfoot.com>...
>Hello,
>
>I have an app with a JFrame-based  window and some JDialog-based
>pop-ups.  Several types of long jobs can be started from buttons or pull
>down menus.  Most of the jobs require one or more pop ups to confirm
>actions, etc.
>
>I'm using a callback scheme where the long job is broken into several
>functions so that it can do some work, get info through a pop up, do
>some more work, get info through a pop up, etc.  Each time the function
>registers a callback with the pop up class, so that the next function in
>the chain gets called when the user clicks OK on the pop up.
>
>Despite the dispose() call in the OK button click event handler, the pop
>up stays put on screen until the job finishes.  Further, the main window
>never repaints if other apps are dragged across it - until the job
>finishes.  I thought that putting the chain of function and pop up
>window calls in a separate thread would free the window manager to
>repaint, but it has no apparent affect.
>
>The use of a separate thread has complicated managing the appearance of
>the cursor too.  I'd like to have the "hourglass" cursor on during these
>long runs.  But it appears that setCursor() only works in the main
>thread, which will be tough to manage when the work is in a separate
>thread...
>
>This seems like the type of thing that would come up a lot - so there
>must be a way to make this work.  Can anyone enlighten me?
>
>Thanks,
>Bill
>
>--
>William P. Glocker
>Voice: 719-598-6854
>email: bill.glocker@bigfoot.com
>
>
Technical Details
Message-ID: <77lr0c$1hg10@forums.borland.com>
Path: arc1-ca.pugleaf.net!unknown!not-for-mail
References: <369E31E2.51EE54DC@bigfoot.com>

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 111d45,3339ffd3981ba964
X-Google-Attributes: gid111d45,public
From: "Matt Krevs" <mattkrevs@flex.com.au>
Subject: Re: long jobs, repainting, and cursor mgmt
Date: 1999/01/15
Message-ID: <77lr0c$1hg10@forums.borland.com>
X-Deja-AN: 432713441
References: <369E31E2.51EE54DC@bigfoot.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Organization: Another Netscape Collabra Server User
Newsgroups: borland.public.jbuilder.java.swing