I'd avoid application.processmessages in 90% of cases. It requires you to take extra care to block messages that may interfere with your processing.
A simple refresh() will do the trick. Certainly using processmessages can work. But beware of any postMessage() or SendMessage() calls being bounced off the form, including windows messages, mouse/button clicks, roll-overs... etc. The short solution is to call TForm.enabled := false which allows the form to paint, but beeps when you try to click on it (which isn't really much more useful than refresh()). I'm not sure if it will drop any custom (WM_USER) messages while the form is disabled. Yet another solution is to write a FOR loop in a base-class form that cycles through the controls[] array property and disables all controls on the form individually. (this will allow you to move and resize the form ... as long as application.processmessages is occasionally called in your processing loops... but all the buttons and controls will be disabled on it, plugging up the holes. In general though, using application.processmessages can lead to unforseen AVs due to things happening in orders that you don't expect. I agree that the most elegant soluition is a separate thread for processing though. It's not too difficult as long as you don't want to update the UI while this processing is taking place. But its really only worth it if you're willing to put some care into it. 15 seconds of processing seems not-quite-worth-the-effort of a separate thread. ----- Original Message ----- From: "Rob Kennedy" <[EMAIL PROTECTED]> To: "Borland's Delphi Discussion List" <[email protected]> Sent: Friday, November 18, 2005 1:32 AM Subject: Re: Updating form with hourglass cursor. > John Dammeyer wrote: >> I have saved the current screen cursor and changed it to an hourglass. I >> then do some extensive processing ultimately building a series of pdf >> pages >> stored to disk. This can take up to 15 seconds. The problem is that the >> screen's cursor doesn't change to an hourglass. What do I call inside >> the >> function to get the screen to repaint. >> >> I've tried self.paint and self.invalidate both which I believe just tell >> windows that the next time it feels like it that the form should be >> repainted and the cursor updated. > > The cursor image is not part of the form image. > >> There must be someway to tell Windows to do this. Suggestions? > > Screen.Cursor really doesn't control the cursor for the entire screen. > It only affects the cursor while it's positioned over one of your > program's forms. > > Windows decides what cursor to display by asking your forms what to > show. It does that by sending a message. If your program truly is busy > generating files, then it probably isn't processing messages, and so > Windows's requests go unanswered until you're finished generating the > files. > > The best solution to this is to generate the files in a separate thread. > That way, your UI thread can continue processing messages as usual. This > includes cursor messages as well as painting messages. It also includes > messages sent when the user clicks the "Cancel" button to stop > processing the files. > > The lesser solution is to occasionally call Application.ProcessMessages > to let your program catch up with whatever's been sent recently. > > -- > Rob > _______________________________________________ > Delphi mailing list -> [email protected] > http://www.elists.org/mailman/listinfo/delphi > _______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi
