I just got back to the office, so sorry for the delay in replying. I have used the timer in quite a few applications. It does seem to be "placed on hold" during certain commands that run a period of time. Such as Project, etc.
So based upon what I am hearing back... no moving visual feed back to a user during such a PROJECT command is currently available? (Cursors are not an option here) -Bob -- Thompson Technology Consultants LaPorte, IN 46350 219-363-7441 -------------- Original message -------------- From: Lawrence Lustig <[EMAIL PROTECTED]> > << > 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? > > 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 > >
