Francois Piette wrote: >> 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). -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html > > -- > [EMAIL PROTECTED] > http://www.overbyte.be > > > ----- Original Message ----- > From: "Arno Garrels" <[EMAIL PROTECTED]> > To: "ICS support mailing" <twsocket@elists.org> > Sent: Thursday, March 22, 2007 10:21 AM > Subject: Re: [twsocket] Architectural question II > > >> Francois PIETTE wrote: >>> We don't need a component at all. We can call the API (like >>> UpdateTimer) in your code and use the component hidden window. There >>> is no conflict possible with the WM_TIMER message. >> >> 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. >> >> Another idea is to have something like a heartbeat dispatcher. >> A singleton class that utilizes a single windows timer, it >> the broadcasts a custom window message to all subscribers. >> Usually you don't need high resolution timers in network >> applications, a lazy heartbeat with let's say a 1 sec resolution >> was precise enough to handle timeouts and other common stuff. >> >> What do you think? >> >> -- >> Arno Garrels [TeamICS] >> http://www.overbyte.be/eng/overbyte/teamics.html >> >>> >>> -- >>> Contribute to the SSL Effort. Visit >>> http://www.overbyte.be/eng/ssl.html -- >>> [EMAIL PROTECTED] >>> http://www.overbyte.be >>> >>> >>> ----- Original Message ----- >>> From: "Arno Garrels" <[EMAIL PROTECTED]> >>> To: "ICS support mailing" <twsocket@elists.org> >>> Sent: Wednesday, March 21, 2007 4:42 PM >>> Subject: Re: [twsocket] Architectural question II >>> >>> >>>> Francois Piette wrote: >>>>>>>> Don't use TTimer in any worker thread since it is NOT thread- >>>>>>>> safe! >>>>>>> >>>>>>> Why is it used in HttpCli then ? >>>>>>> see THttpCli.SendRequest >>>>>> >>>>>> That's true, I would not define UseBandwidthControl in >>>>>> multithreaded applications until a thread-safe timer becomes >>>>>> available. >>>>> >>>>> We could use a bare bone API timer instead. >>>>> What do you think ? >>>> >>>> Something like attached below? It creates its window thread-save, >>>> but I prefer a timer that was able to use the hidden window(s) >>>> of V6, or may be we think about a windowless timer (Thread, >>>> signals, and WaitForMultipleObjects)? >>>> >>>> -- >>>> Arno Garrels [TeamICS] >>>> http://www.overbyte.be/eng/overbyte/teamics.html >>>> >> >> -- >> 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 -- 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
