Hello,
barry wrote:Now i'm wondering if we need to implement multiple multimedia timers or have one multimediatimer where we check if we need to send the frame or not based on a counter (multiple of interval)...
the only person who can answer this is you. This depends on how your communication looks like and how your code is (or should be) arranged. My guess would be:
- If you want to have a function in your DLL that is used for sending frames from somewhere in your code, then you should use a kind of Queue, and use one timer to send that data periodically.
- If you need to send fragmented data (several consecutive frames) where the time between frames vary, then you should use one timer for each send procedure (creating/deleting the timer for each procedure).
barry wrote:I assume if we use 20 x 10 = 200 multimediatimer (20 can channels x 10 frames each) the system will be stressed. So maybe the one multimediatimer approach is beter.
Actually, timers are only windows objects that act as "events", which are triggered by the system when a configured interval elapsed, all based in one central (Windows) tick counter. The amount of objects that can be created is very high and current computer systems can handle them too. 200 Timers shouldn't be a problem, but the need of so many timers for one application is normally an indication of bad design.