Windowless ActiveX control in WTL
-
I'd like to know how to host a windowless ActiveX control in WTL, a Flash control in particular. In MFC, I add it to the dialog via the resource editor, change the control's window property to transparent and when I run the program I see in the debug output that 'Control wants to be windowless'. And indeed, the flash control is completely transparent. But when I follow the same steps in WTL, I can't get the control to lose its window. Thanks :)
-
I'd like to know how to host a windowless ActiveX control in WTL, a Flash control in particular. In MFC, I add it to the dialog via the resource editor, change the control's window property to transparent and when I run the program I see in the debug output that 'Control wants to be windowless'. And indeed, the flash control is completely transparent. But when I follow the same steps in WTL, I can't get the control to lose its window. Thanks :)
You always get a window that hosts the window less control. It might be the case that in MFC, the dialog itself acts as a host for a window less control. Not sure about that. But if you use the CAxWindow class in ATL (suitable for WTL), it'll contain one window for window less controls (the hosting window) and two windows for windowed controls (one window for hosting the control, and one window which is the control itself). I'd advise you to use CAxWindow. It's fast and easy. Be aware of problems however if you are using WTL 3.x/7.0 with ATL7. WTL 3.x/7.0 uses the old ATL3 way of dealing with CComModules, which can be a hassle if you don't know the "tricks" (assertions firing all the time :|) -- Watcha' gonna do, when Hulkamania runs wild on you!?
-
You always get a window that hosts the window less control. It might be the case that in MFC, the dialog itself acts as a host for a window less control. Not sure about that. But if you use the CAxWindow class in ATL (suitable for WTL), it'll contain one window for window less controls (the hosting window) and two windows for windowed controls (one window for hosting the control, and one window which is the control itself). I'd advise you to use CAxWindow. It's fast and easy. Be aware of problems however if you are using WTL 3.x/7.0 with ATL7. WTL 3.x/7.0 uses the old ATL3 way of dealing with CComModules, which can be a hassle if you don't know the "tricks" (assertions firing all the time :|) -- Watcha' gonna do, when Hulkamania runs wild on you!?
-
Thanks for the reply, but I still have no idea what I have to do :confused: Are you suggesting the problem is with my base class, CAxDialogImpl? Or should I subclass the control's window in a certain way? Thanks BTW, I'm using WTL 7.1.
I just had a peek at the implementation of CAxDialogImpl. I saw that it uses CAxWindow (and CAxWindow2) for hosting the actual controls. It does not host the controls directly, hence you'll always get at least one window per activex control. There's not much you can do, unless you implement your own dialog which hosts the controls directly (tricky business). But what's so wrong with an extra window? Your control will function properly! -- Watcha' gonna do, when Hulkamania runs wild on you!?
-
I just had a peek at the implementation of CAxDialogImpl. I saw that it uses CAxWindow (and CAxWindow2) for hosting the actual controls. It does not host the controls directly, hence you'll always get at least one window per activex control. There's not much you can do, unless you implement your own dialog which hosts the controls directly (tricky business). But what's so wrong with an extra window? Your control will function properly! -- Watcha' gonna do, when Hulkamania runs wild on you!?
This is bad news, because my intentions were to experiment with a GUI completely built in flash, and I can't do it with window background around it (if I want to use WTL, that is). Nonetheless, I thank you for your efforts and clarifications! But before I give up on WTL to do this job, can you give me some hints about hosting the control directly? How much coding and knowledge does it involve?
-
This is bad news, because my intentions were to experiment with a GUI completely built in flash, and I can't do it with window background around it (if I want to use WTL, that is). Nonetheless, I thank you for your efforts and clarifications! But before I give up on WTL to do this job, can you give me some hints about hosting the control directly? How much coding and knowledge does it involve?
Forjer wrote: This is bad news, because my intentions were to experiment with a GUI completely built in flash, and I can't do it with window background around it (if I want to use WTL, that is). Interesting concept. How exactly is the flash stuff supposed to be laid out? Should it cover the entire client area, or can you instantiate windowless flash controls and tie them together in some way? I also don't think you can "escape" the extra window in MFC. I'm not 100% sure about how MFC implements active x control hosting, but I suspect it does it similar to ATL/WTL. Forjer wrote: But before I give up on WTL to do this job, can you give me some hints about hosting the control directly? How much coding and knowledge does it involve? That's quite a daunting task I imagine. There are a number of interfaces you'd need implement.
ATL::CAxHostWindowis a good place to start I guess. IIRC, this is the window I've been talking about which hosts the actual control. Perhaps you could derive from it or use code from it to achieve your goal. -- Watcha' gonna do, when Hulkamania runs wild on you!? -
Forjer wrote: This is bad news, because my intentions were to experiment with a GUI completely built in flash, and I can't do it with window background around it (if I want to use WTL, that is). Interesting concept. How exactly is the flash stuff supposed to be laid out? Should it cover the entire client area, or can you instantiate windowless flash controls and tie them together in some way? I also don't think you can "escape" the extra window in MFC. I'm not 100% sure about how MFC implements active x control hosting, but I suspect it does it similar to ATL/WTL. Forjer wrote: But before I give up on WTL to do this job, can you give me some hints about hosting the control directly? How much coding and knowledge does it involve? That's quite a daunting task I imagine. There are a number of interfaces you'd need implement.
ATL::CAxHostWindowis a good place to start I guess. IIRC, this is the window I've been talking about which hosts the actual control. Perhaps you could derive from it or use code from it to achieve your goal. -- Watcha' gonna do, when Hulkamania runs wild on you!?Jörgen Sigvardsson wrote: Interesting concept. How exactly is the flash stuff supposed to be laid out? Should it cover the entire client area, or can you instantiate windowless flash controls and tie them together in some way? There will be only one flash control which will be the entire client area. Flash can communicate with its hosting program via a special command in its ActionScript, which fires an event. Together with the interface we get a two-way communication. Jörgen Sigvardsson wrote: I also don't think you can "escape" the extra window in MFC. I'm not 100% sure about how MFC implements active x control hosting, but I suspect it does it similar to ATL/WTL. When I try it in MFC I get a debug output of 'control wants to be windowless'. When I override WM_ERASEBKGND, the flash control has no window around it. A search for the debug message led me to the file occsite.cpp, which led me to the ATL class IOleInPlaceObjectWindowlessImpl. I don't know if I can make something useful from the information, as I'm very new to the COM architecture, but if I do I'll probably write an article :)
-
Jörgen Sigvardsson wrote: Interesting concept. How exactly is the flash stuff supposed to be laid out? Should it cover the entire client area, or can you instantiate windowless flash controls and tie them together in some way? There will be only one flash control which will be the entire client area. Flash can communicate with its hosting program via a special command in its ActionScript, which fires an event. Together with the interface we get a two-way communication. Jörgen Sigvardsson wrote: I also don't think you can "escape" the extra window in MFC. I'm not 100% sure about how MFC implements active x control hosting, but I suspect it does it similar to ATL/WTL. When I try it in MFC I get a debug output of 'control wants to be windowless'. When I override WM_ERASEBKGND, the flash control has no window around it. A search for the debug message led me to the file occsite.cpp, which led me to the ATL class IOleInPlaceObjectWindowlessImpl. I don't know if I can make something useful from the information, as I'm very new to the COM architecture, but if I do I'll probably write an article :)
Forjer wrote: There will be only one flash control which will be the entire client area. Flash can communicate with its hosting program via a special command in its ActionScript, which fires an event. Together with the interface we get a two-way communication. CAxWindow will do just fine for you, honest!
CAxWindowoffers an interface much likeCWindow/CWnd. Just make it span over all your client area. First create it with (pseudo code)CAxWindow::Create(hWndParent, clientrect, _T("ProgId.For.Flash"), WS_CHILD | WS_VISIBLE);. Then useCAxWindow::QueryControlto acquire a reference to an interface, which you can advise for events. I'd suggest you create a WTL SDI-project using the WTL wizard. In the wizard, uncheck the "use a view window" checkbox. Click OK to generate project. Then inCMainFrame::OnCreateat the bottom, do something like this:m_hWndClient = m_activex.Create(*this, rcDefault, _T("flash.prog.id or {clsid}"), WS_CHILD | WS_VISIBLE);
UpdateLayout();The frame window will then resize your activex control automatically. About
_T("_flash.prog.id or {clsid}_")see the Create method for CWindow in the MSDN docs. CAxWindow interprets the window text as a control class id/prog id. CAxDialogImpl uses this "trick". It *will* work, and it'll save you from reimplementing the entire OLE hosting code (which is a lot, and not the easiest thing if you're new to COM). Forjer wrote: A search for the debug message led me to the file occsite.cpp, which led me to the ATL class IOleInPlaceObjectWindowlessImpl. That impl stub is used by controls that implement activex interfaces - the interfaceIOleInPlaceObjectWindowlessis used by the container to communicated with the control. -- Watcha' gonna do, when Hulkamania runs wild on you!? -
Forjer wrote: There will be only one flash control which will be the entire client area. Flash can communicate with its hosting program via a special command in its ActionScript, which fires an event. Together with the interface we get a two-way communication. CAxWindow will do just fine for you, honest!
CAxWindowoffers an interface much likeCWindow/CWnd. Just make it span over all your client area. First create it with (pseudo code)CAxWindow::Create(hWndParent, clientrect, _T("ProgId.For.Flash"), WS_CHILD | WS_VISIBLE);. Then useCAxWindow::QueryControlto acquire a reference to an interface, which you can advise for events. I'd suggest you create a WTL SDI-project using the WTL wizard. In the wizard, uncheck the "use a view window" checkbox. Click OK to generate project. Then inCMainFrame::OnCreateat the bottom, do something like this:m_hWndClient = m_activex.Create(*this, rcDefault, _T("flash.prog.id or {clsid}"), WS_CHILD | WS_VISIBLE);
UpdateLayout();The frame window will then resize your activex control automatically. About
_T("_flash.prog.id or {clsid}_")see the Create method for CWindow in the MSDN docs. CAxWindow interprets the window text as a control class id/prog id. CAxDialogImpl uses this "trick". It *will* work, and it'll save you from reimplementing the entire OLE hosting code (which is a lot, and not the easiest thing if you're new to COM). Forjer wrote: A search for the debug message led me to the file occsite.cpp, which led me to the ATL class IOleInPlaceObjectWindowlessImpl. That impl stub is used by controls that implement activex interfaces - the interfaceIOleInPlaceObjectWindowlessis used by the container to communicated with the control. -- Watcha' gonna do, when Hulkamania runs wild on you!?Your efforts are very kind, but I think you missed the point. If I understand the code correctly, it won't make the control windowless, which is my *only* problem. I have to make it windowless because I only want to show the flash GUI and nothing else. The only way I can achieve this without a windowless control would be to build a square GUI - but that would be unesthetic.
-
Your efforts are very kind, but I think you missed the point. If I understand the code correctly, it won't make the control windowless, which is my *only* problem. I have to make it windowless because I only want to show the flash GUI and nothing else. The only way I can achieve this without a windowless control would be to build a square GUI - but that would be unesthetic.
Ah.. then I think you're out of luck. Now, I may be wrong on this one, but I can't seem to find anything in the OLE/activex interfaces which indicate non rectangular controls. -- Watcha' gonna do, when Hulkamania runs wild on you!?