>I figure that the performance/impact on my main .exe (it hosts a few ActiveX controls) would be too strong. What I am thinking now is that I will create a timer (or use the higher-performing one called cpptimer.fll) object and make that into a MTDLL and run that in a COM+ package. That way it can run constantly and since it's in a seperate process space it won't impact my main stuff.


DLLs do not have events. They only respond to external triggers, such as COM method calls. So a timer in a MTDLL will not fire. I'm not familiar with cpptimer.fll, but I'd assume that it sets up an event handler that triggers on VFP null events, which would also not occur in an MTDLL.

Another problem is that, unless you're on a multi-processor machine, the processor will be having to do the same amount of work whether or not you have split the app into two processes. In fact, process switching takes extra work.

I suggest you at least try just using the timer control in your main app. Checking the current SECONDS() value against a memvar a couple times per second should not cause a measurable performance issue. The main problem you might get is if an event or method on an ActiveX control takes a long time to process, it can prevent the timer events from executing at their scheduled times.

If you really need to put the timer in a separate process, don't use a DLL. Build it into a com EXE instead. That way, you can still instantiate it as a com object, and it will still be able to process timer events.

-Tom


(This post is provided "AS-IS" with no warranties, and confers no rights.)