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
