Article View: borland.public.jbuilder.java.swing
Article #12369Re: long jobs, repainting, and cursor mgmt
From: Matt Krevs
Date: Fri, 15 Jan 1999 00:00
Date: Fri, 15 Jan 1999 00:00
65 lines
2985 bytes
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-mailReferences:
<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