>I'm not an expert in this area; but in my humble opinion you're doing >as well as you ever will running in a multi-user operating system >(5/3600 = a 0.14 % error).
I've got other timer-based programs that actually show a countdown in seconds, but I don't think I've tested it against a separate clock. I'll do that to see if I get the same response. >nd suppose a handler is running at the exact moment the message is >sent....the message's handler cannot run until the current handler >and any handlers the current handler calls have completed, and any >handlers they call have been completed, and so on. This is not the case here. It's the simplest of programs. It takes a number (minutes) you enter into a field. It multiplies it by 60. It uses that number in a send routine to execute the reminder in min*60 seconds. That's it. Then it stops and waits for the send to appear. There are no other handlers running (actually, there's a mousemove handler that controls the cursor appearance, but for my tests, the program just ran on my PC, which I never touched for several hours, so the mousemove handler should not have ever been evoked). >I concluded that the performance hits were the result of O/S >"housekeeping" activities that had nothing to do with my app or Rev. Again, in these tests, nothing else was being performed on the PC. It was just sitting there, not being used. I know there are still background processes running, but they should have been minimal. miscdas had the best suggestion to see if playing the .wav file was causing the delay (it shouldn't, but who knows). If that doesn't show anything, I'm back to scratching my head (and thinking you're probably right). Regards, Howard Bornstein ____________________ D E S I G N E Q www.designeq.com _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
