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? 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
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
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
Re: [twsocket] Possible bug and solution in TWndControl
Hello Arno, I am not sure I understand how could more window handles in a single thread would benefit than single window handle! BTW, where is Francois?? Best Regards, SZ - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Tuesday, February 06, 2007 5: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
Re: [twsocket] Possible bug and solution in TWndControl
Fastream Technologies wrote: Hello Arno, I am not sure I understand how could more window handles in a single thread would benefit than single window handle! There is for instance a bigger static array [0..WH_MAX_MSG] of TIcsWndControl.. I would play with the value and find an optimal setting for my application. Only I do not believe that it fixed the root of your ghost-message-problem. BTW, where is Francois?? AFAIK he's currently very busy. --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html Best Regards, SZ - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Tuesday, February 06, 2007 5: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
Re: [twsocket] Possible bug and solution in TWndControl
BTW, where is Francois?? I'm here but working on a big contract. Sorry but free support is given after everything else is done. -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be - Original Message - From: Fastream Technologies [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Tuesday, February 06, 2007 5:13 PM Subject: Re: [twsocket] Possible bug and solution in TWndControl Hello Arno, I am not sure I understand how could more window handles in a single thread would benefit than single window handle! BTW, where is Francois?? Best Regards, SZ - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Tuesday, February 06, 2007 5: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
Re: [twsocket] Possible bug and solution in TWndControl
Hi, It is just a simple constant, why shouldn't it be 800 instead of 100?? Because it is not the source of a bug. No need to change anything if it is not buggy. Changing it and then your code works does not prove there is a bug. --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz -- 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
Re: [twsocket] Possible bug and solution in TWndControl
Ok. Then there is a bug in ThreadAttach/Detach which Arno said he did not test against. Because my code is so simple! It just has three custom messages in WM_USER + 100-103 and the ICS messages are in WM_APP + 100. The only possibility is that my init code in the client thread is bad (see the first message of the thread). Regards, SZ - Original Message - From: Wilfried Mestdagh [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Tuesday, February 06, 2007 10:17 PM Subject: Re: [twsocket] Possible bug and solution in TWndControl Hi, It is just a simple constant, why shouldn't it be 800 instead of 100?? Because it is not the source of a bug. No need to change anything if it is not buggy. Changing it and then your code works does not prove there is a bug. --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz -- 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
