> I think Francois knows why he choosed 100 as the limit. This is completely arbitrary. Too much messages means less performance. Too less messages means too much windows. There is a tradeoff each one could adjust to his needs.
-- 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: Tuesday, February 06, 2007 4:20 PM Subject: Re: [twsocket] Possible bug and solution in TWndControl > Fastream Technologies wrote: >> Despite all have been said, I still think that 100 messages/thread is >> low. >> It should be at least 400-600. > > WH_MAX_MSG does not specify the maximum possible number of messages > in a thread but maximum messages handled by a single hidden window > before a new window will be created. Let's assume TWSocket requires > 12 message numbers the one hidden window could handle 96 message > numbers or 8 different instances of TWSocket created in the same > thread. 80 instances would create 10 hidden windows. I think > Francois knows why he choosed 100 as the limit. > > While writing this it comes to my mind that you might not have > overridden MsgHandlersCount correctly. Each custom message that is > registered by AllocateMsgHandlers() must increment MsgHandlersCount > as well as need to be unregistered by FWndHandler.UnregisterMessage. > > --- > Arno Garrels [TeamICS] > http://www.overbyte.be/eng/overbyte/teamics.html > > >> Regards, >> >> SZ >> >> ----- Original Message ----- >> From: "Arno Garrels" <[EMAIL PROTECTED]> >> To: "ICS support mailing" <twsocket@elists.org> >> Sent: Tuesday, February 06, 2007 2:39 PM >> Subject: Re: [twsocket] Possible bug and solution in TWndControl >> >> >>> What about using RegisterWindowMessage to let windows give you a >>> value for >>> the windows-message not beeing in use? >> >> Messages are sent/posted either to a unique window handle >> or to a unique thread-ID so the message numbers must neither >> be unique in the application nor in the system. Commonly you >> would receive 'ghost' messages only if the own application >> sent/posted messages to the hidden component window with a >> message number not previously registered and mapped by >> AllocateMsgHandler() in the right thread. >> AFAIK BroadcastSystemMessage() can be called with messages >> registered by RegisterWindowMessage() only. So if there's >> no bad application explicitely spying for the hidden window >> and sending it a message that ICS handles everything >> should work just fine, no difference to V5. Third party >> components and their message numbers should not conflict >> (my previous email was probably a bit confusing). >> >> Finally there may be a bug in V6, but so far I think this >> chance is very low, since I've been playing with and stress >> tested a multi-threaded V6 server back in 2006 and I had no >> such problems with message numbers at all, my server did not >> call ThreadDetach/ThreadAttach but used a pool of TWSocket >> clients allocated and managed in each thread. My guess is >> that SZ still has synchronization bug(s) in his multi-threaded >> application that cause strange, subsequent errors. Anyway >> hard to debug. >> >> --- >> Arno Garrels [TeamICS] >> http://www.overbyte.be/eng/overbyte/teamics.html >> >> >> Bjørnar Nielsen wrote: >>> What about using RegisterWindowMessage to let windows give you a >>> value for >>> the windows-message not beeing in use? Usually this procedure is used >>> when >>> sending windows messages between applications. But I don't see a >>> reason for >>> not using this inside the application also. If we give the windows >>> message a >>> name that is safe to assume that no other application would use, then >>> we >>> would have a message that no other applications/librarys use. >>> >>> For those not familiar with this procedure, this is how it works: >>> const int MY_CUSTOM_MESSAGE = >>> RegisterWindowMessage("MY_CUSTOM_MESSAGE"); >>> >>> The first time this is called after a reboot, windows will reserve a >>> value >>> for the message-name and return it. The next time the procedure is >>> called >>> with the same string, it will return the same value as earlier. >>> >>> Regards Bjørnar >>> >>>> I still recommend to find the sender of that anonymous >>>> message as well as find a reliable range of message numbers >>>> that can be used by ICS V6 exclusively. Who knows whether >>>> there is still a strange third party message being processed >>>> that you do not note because it simply doesn't raise the test >>>> exception but triggers a ICS event? In other words I always >>>> would try to find the root of the problem. >> -- >> 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 > -- 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
