Francois PIETTE wrote: > In V6, this is a single window for all timers in a single thread. > In V5, there is a window for each component and that window is used > for the timer. > So in both cases, there not a single hidden window dedicated to the > timers.
That's true, however it does not solve the main problem with timers in ICS. The general problem with timers (beside the question which window to use) is that they are a limited resource. If we want support of "timer per instance" we have to take into account that: 1.) Win9x allows 32 timers systemwide only. 2.) WinNT supports 16 timers per process only. 3.) Maximum size of a thread's message queue is limited (default 10000). In W2K and above it's possible to create thousands of timers (I stopped testing at 10000 yesterday). However if we want support for "timer per instance" in older OSs as well we have to emulate this capability somehow. There are components around (like TTimerList of RX-Library) promising to work around those limits. But they are slow. Such a timer list utilizes a single Windows timer set to the shortest interval of all registered timer-events. When the timer fires it looks up and triggers registered timer-events as needed. The procedure of adding/removing events is slow as well and may cause delay if the timer interval must be reset. Also such a global timer list must be thread-safe which slowed down performance again. If you think we need such a 'polling beast' in order to work around limits of older OSs, we should write a faster and smarter one that could i.e. use an AVL-tree to manage its list of timer-events. What do you think? -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html >>>> I do not understand who shall handle the WM_TIMER messages? >>>> Currently TIcsWndControl skips message numbers below WM_USER, >>>> do you want to change that? WParam of WM_TIMER can hold a >>>> custom 32 bits value like an object reference. >>> >>> In V5, the component hidden window can handle the message. >>> In V6, TIcsWndControl can handle it. Just a little bit more clever >>> since it is shared by many components. >>> One way is to derive from TIcsWndControl to implement a general >>> timer feature and then modify the inheritence chain for all >>> controls needing timers. This to avoid having timer stuff for all >>> components. >> >> That's an improvement, no question, however still means one Windows >> timer per instance. Certainly a couple of timers won't be a problem, >> expecially in newer Windows versions, however I have my doubts that >> creating hundreds of timers was a very good idea, if possible at all >> (NT allowed 16 timers per process only). > > In V6, this is a single window for all timers in a single thread. > In V5, there is a window for each component and that window is used > for the timer. > So in both cases, there not a single hidden window dedicated to the > timers. > > -- > [EMAIL PROTECTED] > The author for the freeware multi-tier middleware MidWare > The author of the freeware Internet Component Suite (ICS) > http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
