----- Original Message ----- From: "Lawrence Lustig" <[EMAIL PROTECTED]> To: "RBASE-L Mailing List" <[email protected]> Sent: Friday, July 18, 2008 3:45 PM Subject: [RBASE-L] - Re: Animated GIF object
> << > The timer runs in its' own thread, so ProcessMessage should give the message > loop a breather for screen updates. >>> > > Is this true? I was under the impression that the timer was actually run > inside Windows, which dispatches a message (WM_TIMER, I think) back to the > application's main thread when the timer "goes off". If the main thread is > blocked (as with a long call into the RBENGINE.DLL) it strikes me that the > timer message might not make it, or might not be seen by the application in a > timely fashion. > > Have you actually tried this -- setting a timer and then somehow blocking on > the winmain() thread to see if the timer gets executed? > My workaround was to call a hidden (alphablended to invisible ) MDI form (with an alias, so I could CLOSEWINDOW "aliasname" ) that used a combo of GetTickCount and Sleep APIs in a While Loop and PROCESSMESSAGE in the loop and set Sleep to something unobtrusive like 1000 or 1500. It seems to be independent of the grind. > If this is the case, I imagine you might be able to work around it by > including a call to a stored procedure in you SQL statement; a stored > procedure that include a PROCESSMESSAGES statement. But it would slow down > your SQL. > -- > Larry > > >
