> 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
