Message for invisible control ?
-
Hello ! 1. Sorry for my English 2. Bloody beginner 3. I have a ATL Full Control, invisible at runtime. It is placed in a HTML Page with the Tag. There is a custom Message: ----------------------------------------------------- #define MY_TEST (WM_APP + 1) .... LRESULT OnTest(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled); .... BEGIN_MSG_MAP(CmyClass14) CHAIN_MSG_MAP(CComControl ) DEFAULT_REFLECTION_HANDLER() MESSAGE_HANDLER(MY_TEST, OnTest) END_MSG_MAP() ----------------------------------------------------- OK. Compiles fine. But how do I Post my Message? Here is what I tried: PostMessage(MY_TEST) or ::PostMessage(this->m_hWnd, MY_TEST, 0, 0) gives me an Assertion failure at runtime with "::IsWindow(hWnd)" That tells me PostMessage needs a Window. (?) PostThreadMessage(GetCurrentThreadID(), MY_TEST, 0, 0) or ::PostThreadMessage(GetCurrentThreadID(), MY_TEST, 0, 0) works, but the message handler OnTest is never called. What can I do ??? MfG Sebastian
-
Hello ! 1. Sorry for my English 2. Bloody beginner 3. I have a ATL Full Control, invisible at runtime. It is placed in a HTML Page with the Tag. There is a custom Message: ----------------------------------------------------- #define MY_TEST (WM_APP + 1) .... LRESULT OnTest(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled); .... BEGIN_MSG_MAP(CmyClass14) CHAIN_MSG_MAP(CComControl ) DEFAULT_REFLECTION_HANDLER() MESSAGE_HANDLER(MY_TEST, OnTest) END_MSG_MAP() ----------------------------------------------------- OK. Compiles fine. But how do I Post my Message? Here is what I tried: PostMessage(MY_TEST) or ::PostMessage(this->m_hWnd, MY_TEST, 0, 0) gives me an Assertion failure at runtime with "::IsWindow(hWnd)" That tells me PostMessage needs a Window. (?) PostThreadMessage(GetCurrentThreadID(), MY_TEST, 0, 0) or ::PostThreadMessage(GetCurrentThreadID(), MY_TEST, 0, 0) works, but the message handler OnTest is never called. What can I do ??? MfG Sebastian
Hi there, Sorry I don't have an answer for you, mainly because I don't know/understand what are you trying to do, but, I have a couple of comments for you. First never do something like this to obtain a message id
#define MY_TEST (WM_APP + 1)
somebody else can be using the same id for a different message, always useUINT RegisterWindowMessage( LPCTSTR lpString /* message string */ );
for your messages, this API guarantee the returning id is unique. Second, why do you use a Control that is invisible at RunTime?, if your object has no visible interface, it may be better to use a Single object or even an ATL Class. Post a brief description of what are you trying to achieve, I may be able to help you. Regards, Fabian -
Hi there, Sorry I don't have an answer for you, mainly because I don't know/understand what are you trying to do, but, I have a couple of comments for you. First never do something like this to obtain a message id
#define MY_TEST (WM_APP + 1)
somebody else can be using the same id for a different message, always useUINT RegisterWindowMessage( LPCTSTR lpString /* message string */ );
for your messages, this API guarantee the returning id is unique. Second, why do you use a Control that is invisible at RunTime?, if your object has no visible interface, it may be better to use a Single object or even an ATL Class. Post a brief description of what are you trying to achieve, I may be able to help you. Regards, FabianI will try to explain the idea: The article "Firing Events among ActiveX Controls on the IE Browser" by Yasuhiko Yoshimura ( http://www.codeproject.com/com/firingeventsamongactivex.asp ) showed me a way to link up multiple client-controls to a server-control. The client-controls in my scenario are visualisations of data fired from the server-control. The server-control is a "interface" with no UI which: 1. Links up to a 3rd-Party-Queueing-System... 2. ... processes the incoming data... 3. ... and fires events to the client-controls for visualisation. And so the server-control shall be invisible. HTML-Page: .... But all this lays in far future. My Problem: The invisible server-control has to catch custom messages (defined by the 3rdPartyAPI). To simplify things and for testing I try to catch my own WM_APP+1 message. And in the way I'm trying to post/map my message it doesn't work. Was my explaining OK? Any idea will help me a lot. MfG Sebastian
-
I will try to explain the idea: The article "Firing Events among ActiveX Controls on the IE Browser" by Yasuhiko Yoshimura ( http://www.codeproject.com/com/firingeventsamongactivex.asp ) showed me a way to link up multiple client-controls to a server-control. The client-controls in my scenario are visualisations of data fired from the server-control. The server-control is a "interface" with no UI which: 1. Links up to a 3rd-Party-Queueing-System... 2. ... processes the incoming data... 3. ... and fires events to the client-controls for visualisation. And so the server-control shall be invisible. HTML-Page: .... But all this lays in far future. My Problem: The invisible server-control has to catch custom messages (defined by the 3rdPartyAPI). To simplify things and for testing I try to catch my own WM_APP+1 message. And in the way I'm trying to post/map my message it doesn't work. Was my explaining OK? Any idea will help me a lot. MfG Sebastian
Hi I think I'm starting to understand what you are trying to do. The fact of having several objects hosted on IE is irrelevant to your problem, isn't it? The real issue here is how to capture messages from a 3rd party package, am I right? So, let me ask you, is this 3rd party queueing system a COM based server or not?, if it is so, it should communicate using event and not messages. The article that you mentioned, "Firing Events among ActiveX Controls on the IE Browser", clearly talks about events and not messages. If it is not a COM server, can you show me a piece of documentation how it is suppose to communicate back to your code? I'm saying this because is very unusual for a library to send messages to a client, usually this is done through call back functions, so what you are saying sounds a litle odd. Anyways, comments aside, here is how you can do the test you mentioned before. First, declare the id of the message you will use. Add this line to the stdafx.h file so it will be available to the whole project
//This is the declaration of the message id extern UINT UM_MYTESTMESSAGE;
now define its value. Add this into your cpp file.//Make sure this string is unique. //Usually the name of the massage plus the name of the application is enough. //The returning ID will be unique UINT UM_MYTESTMESSAGE = ::RegisterWindowMessage(_T("MyAppNameMyMessageName"));
Now how to capture the message, if your class derives directly or indirectly from a CWindowImpl it has a BEGIN_MSG_MAP macro, so add this lineBEGIN_MSG_MAP(CMyTest) MESSAGE_HANDLER(UM_MYTESTMESSAGE, OnMyMessageTest) //this is the one you add ... it may be something else here END_MSG_MAP()
Then you have to provide the OnMyMessageTest implementation, so add thisLRESULT OnMyMessageTest(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled) { MessageBox(_T("I got the message ")); return 0; };
And last, somebody has to send the message to this window, and I think here is where you have the problem, answering your question, yes, messages can only be send to a valid window, if you got an assertion hereATLASSERT(::IsWindow(m_hWnd));
is because you sent the message when the window was not yet created, so, choose a place where the window you are send the message to, has already been created, then add this line::SendMessage(hWnd, UM_MYTESTMESSAGE, 0, 0);
-
Hi I think I'm starting to understand what you are trying to do. The fact of having several objects hosted on IE is irrelevant to your problem, isn't it? The real issue here is how to capture messages from a 3rd party package, am I right? So, let me ask you, is this 3rd party queueing system a COM based server or not?, if it is so, it should communicate using event and not messages. The article that you mentioned, "Firing Events among ActiveX Controls on the IE Browser", clearly talks about events and not messages. If it is not a COM server, can you show me a piece of documentation how it is suppose to communicate back to your code? I'm saying this because is very unusual for a library to send messages to a client, usually this is done through call back functions, so what you are saying sounds a litle odd. Anyways, comments aside, here is how you can do the test you mentioned before. First, declare the id of the message you will use. Add this line to the stdafx.h file so it will be available to the whole project
//This is the declaration of the message id extern UINT UM_MYTESTMESSAGE;
now define its value. Add this into your cpp file.//Make sure this string is unique. //Usually the name of the massage plus the name of the application is enough. //The returning ID will be unique UINT UM_MYTESTMESSAGE = ::RegisterWindowMessage(_T("MyAppNameMyMessageName"));
Now how to capture the message, if your class derives directly or indirectly from a CWindowImpl it has a BEGIN_MSG_MAP macro, so add this lineBEGIN_MSG_MAP(CMyTest) MESSAGE_HANDLER(UM_MYTESTMESSAGE, OnMyMessageTest) //this is the one you add ... it may be something else here END_MSG_MAP()
Then you have to provide the OnMyMessageTest implementation, so add thisLRESULT OnMyMessageTest(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled) { MessageBox(_T("I got the message ")); return 0; };
And last, somebody has to send the message to this window, and I think here is where you have the problem, answering your question, yes, messages can only be send to a valid window, if you got an assertion hereATLASSERT(::IsWindow(m_hWnd));
is because you sent the message when the window was not yet created, so, choose a place where the window you are send the message to, has already been created, then add this line::SendMessage(hWnd, UM_MYTESTMESSAGE, 0, 0);
First of all thanks a lot for your effort to help me. - The queueing system is a non-COM service. It uses messages to signal the queue-clients for incoming data. - My invisible control is such a queue-client. - My invisible control uses events to distribute the data-values to the other controls which visualize them. It would be no problem if my invisible control wouldn't be invisible. It seems to me that there is no window created if a control is marked "invisible" (which was a little mislead to me). I tried to create a window inside my control, but this fails, too... X| So I surrender and use the other possibility. My windowless control creates a thread which captures the queue-messages and fires the events.... ...but multithreaded event-firing makes me shiver. MfG, Sebastian