Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. ATL / WTL / STL
  4. Message for invisible control ?

Message for invisible control ?

Scheduled Pinned Locked Moved ATL / WTL / STL
questionc++htmllearning
5 Posts 2 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • S Offline
    S Offline
    Sebastian S
    wrote on last edited by
    #1

    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

    F 1 Reply Last reply
    0
    • S Sebastian S

      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

      F Offline
      F Offline
      f64
      wrote on last edited by
      #2

      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 use UINT 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

      S 1 Reply Last reply
      0
      • F f64

        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 use UINT 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

        S Offline
        S Offline
        Sebastian S
        wrote on last edited by
        #3

        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

        F 1 Reply Last reply
        0
        • S Sebastian S

          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

          F Offline
          F Offline
          f64
          wrote on last edited by
          #4

          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 line BEGIN_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 this LRESULT 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 here ATLASSERT(::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);

          S 1 Reply Last reply
          0
          • F f64

            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 line BEGIN_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 this LRESULT 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 here ATLASSERT(::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);

            S Offline
            S Offline
            Sebastian S
            wrote on last edited by
            #5

            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

            1 Reply Last reply
            0
            Reply
            • Reply as topic
            Log in to reply
            • Oldest to Newest
            • Newest to Oldest
            • Most Votes


            • Login

            • Don't have an account? Register

            • Login or register to search.
            • First post
              Last post
            0
            • Categories
            • Recent
            • Tags
            • Popular
            • World
            • Users
            • Groups