ActiveX control as parent
-
Hi all, Are you concentrating? Yes, good! Please read this carefully An example of my problem is I have three controls.
- Control A
- Control B1
- Control B2
I want to be able to either B1 or B2 to be a child window of A depending on how I set the properties. Of course I know A is child window. when I place it on the a driver (demo) app, it crashing my system. I want to know to do this safely? Many thanks, alton
-
Hi all, Are you concentrating? Yes, good! Please read this carefully An example of my problem is I have three controls.
- Control A
- Control B1
- Control B2
I want to be able to either B1 or B2 to be a child window of A depending on how I set the properties. Of course I know A is child window. when I place it on the a driver (demo) app, it crashing my system. I want to know to do this safely? Many thanks, alton
Hi Alton! If you find the part below hard to understand, please let me know and I'll repost typing it slower. ;)
Alton Williams wrote:
Of course I know A is child window. when I place it on the a driver (demo) app, it crashing my system.
How does it crash your system? Error messages? Some info from debug sessions? The "system" could crash from a zillion reasons, give or take a few, it's quite hard to guess what your problem is. -- Roger
_It's supposed to be hard, otherwise anybody could do it!
Regarding CodeProject: "resistance is pointless; you will be assimilated"_
-
Hi Alton! If you find the part below hard to understand, please let me know and I'll repost typing it slower. ;)
Alton Williams wrote:
Of course I know A is child window. when I place it on the a driver (demo) app, it crashing my system.
How does it crash your system? Error messages? Some info from debug sessions? The "system" could crash from a zillion reasons, give or take a few, it's quite hard to guess what your problem is. -- Roger
_It's supposed to be hard, otherwise anybody could do it!
Regarding CodeProject: "resistance is pointless; you will be assimilated"_
Hi Roger, Thanks for your prompt reply!
Roger Stoltz wrote:
How does it crash your system? Error messages? Some info from debug sessions?
When I build and register the control. When I place it on another form (in VB) or Dialogue box (in VC++) for testing. it seems to bring down VB or VC++. If I'm lucky if my final app comes down or doesn't respond at run-time. Is that any clearer? Alton
-
Hi Roger, Thanks for your prompt reply!
Roger Stoltz wrote:
How does it crash your system? Error messages? Some info from debug sessions?
When I build and register the control. When I place it on another form (in VB) or Dialogue box (in VC++) for testing. it seems to bring down VB or VC++. If I'm lucky if my final app comes down or doesn't respond at run-time. Is that any clearer? Alton
Alton Williams wrote:
When I build and register the control.
I interpret this as you get an assertion or runtime error when you try to register the component after a successful build. Correct? What happens if you try to register the component outside DevStudio? If it crashes even then I suggest you try to debug the component by selecting RegSvr32.exe as the executable for debug session, provide the complete path to your debug-built component as argument and "run" your component (F5). Put a breakpoint inside DllRegisterServer() and step through the registration call chain. If you don't get any clues from this exercise; post again and describe what happens, what error messages you're getting and where.
Alton Williams wrote:
When I place it on another form (in VB) or Dialogue box (in VC++) for testing. it seems to bring down VB or VC++. If I'm lucky if my final app comes down or doesn't respond at run-time.
If the registration isn't successful you may get various errors when you try to use the component, e.g. inserting it to a client or running the final app. In other words: let's fix the registration first if it doesn't work. -- Roger
_It's supposed to be hard, otherwise anybody could do it!
Regarding CodeProject: "resistance is pointless; you will be assimilated"_
-
Alton Williams wrote:
When I build and register the control.
I interpret this as you get an assertion or runtime error when you try to register the component after a successful build. Correct? What happens if you try to register the component outside DevStudio? If it crashes even then I suggest you try to debug the component by selecting RegSvr32.exe as the executable for debug session, provide the complete path to your debug-built component as argument and "run" your component (F5). Put a breakpoint inside DllRegisterServer() and step through the registration call chain. If you don't get any clues from this exercise; post again and describe what happens, what error messages you're getting and where.
Alton Williams wrote:
When I place it on another form (in VB) or Dialogue box (in VC++) for testing. it seems to bring down VB or VC++. If I'm lucky if my final app comes down or doesn't respond at run-time.
If the registration isn't successful you may get various errors when you try to use the component, e.g. inserting it to a client or running the final app. In other words: let's fix the registration first if it doesn't work. -- Roger
_It's supposed to be hard, otherwise anybody could do it!
Regarding CodeProject: "resistance is pointless; you will be assimilated"_
Hello Roger, Sorry I've a while to answer your question
Roger Stoltz wrote:
Alton Williams wrote: When I build and register the control. I interpret this as you get an assertion or runtime error when you try to register the component after a successful build. Correct?
No, Rog! It builds and get registered perfectly when I place the end result onto another project be it VC dialogue or a VB form the aproppriate developer app (MSVC6 or MSVB6) crashes. I if it would be a HWND problem I'll explain the issue more clearly. I've created three controls;
- A control called child1ctrl which is a subclass of "EDIT"
- Another called child2ctrl is that of "STATIC"
- A third one called holderctrl which isn't subclassed
Firstly, I design controls 1 & 2 individually either as single project or two projects (that's not relevant). Naturally it builds and registers the two controls ok. At this stage when add either (1 or 2) to other projects. Works perfectly. It's when I am design control no 3. I'm what is the cause for concern I do the follow
- I go through the wizard:doh:
- I add controls (1 and 2) to the project and it generates the wrapper classes.(CChild1 & CChild2)
- I make these as two member variables one of each class.
- I write code to create the two child windows
I have no problems with build and the control registers with no problems. Its when I add HolderControl onto other projects I drag and drop it on a diaglogue box and crashes VC++ (msdev.exe). Likewise I do it on a for VB (VB.exe) comes down. To begin with I wrongfully wrote code to create (1 & 2) in WM_CREATE.
class CHolder{ virtual void PreSubclassWindow(); private: CChild1 m_ctrl1; CChild2 m_ctrl2; BOOL m_bFlag
Then
void CHolderCtrl::PreSubclassWindow() { m_bFlag = m_ctrl1.CreateControl(clsid, NULL, dwStyle, rect, this) && m_ctrl2.CreateControl(clsid, NULL, dwStyle, rect, this); COleControl::PreSubclassWindow(); }
On debugging what is causing the crashing seems lie with the first call to create for the first "window" so the second call doesn't happen.:confused::confused: MS Calendar Control 8.0 dosen't behave like this. I has two child ComboBoxes and 50 Statics on it. I don't if I'm clearer now. I going to repost the questio
-
Hello Roger, Sorry I've a while to answer your question
Roger Stoltz wrote:
Alton Williams wrote: When I build and register the control. I interpret this as you get an assertion or runtime error when you try to register the component after a successful build. Correct?
No, Rog! It builds and get registered perfectly when I place the end result onto another project be it VC dialogue or a VB form the aproppriate developer app (MSVC6 or MSVB6) crashes. I if it would be a HWND problem I'll explain the issue more clearly. I've created three controls;
- A control called child1ctrl which is a subclass of "EDIT"
- Another called child2ctrl is that of "STATIC"
- A third one called holderctrl which isn't subclassed
Firstly, I design controls 1 & 2 individually either as single project or two projects (that's not relevant). Naturally it builds and registers the two controls ok. At this stage when add either (1 or 2) to other projects. Works perfectly. It's when I am design control no 3. I'm what is the cause for concern I do the follow
- I go through the wizard:doh:
- I add controls (1 and 2) to the project and it generates the wrapper classes.(CChild1 & CChild2)
- I make these as two member variables one of each class.
- I write code to create the two child windows
I have no problems with build and the control registers with no problems. Its when I add HolderControl onto other projects I drag and drop it on a diaglogue box and crashes VC++ (msdev.exe). Likewise I do it on a for VB (VB.exe) comes down. To begin with I wrongfully wrote code to create (1 & 2) in WM_CREATE.
class CHolder{ virtual void PreSubclassWindow(); private: CChild1 m_ctrl1; CChild2 m_ctrl2; BOOL m_bFlag
Then
void CHolderCtrl::PreSubclassWindow() { m_bFlag = m_ctrl1.CreateControl(clsid, NULL, dwStyle, rect, this) && m_ctrl2.CreateControl(clsid, NULL, dwStyle, rect, this); COleControl::PreSubclassWindow(); }
On debugging what is causing the crashing seems lie with the first call to create for the first "window" so the second call doesn't happen.:confused::confused: MS Calendar Control 8.0 dosen't behave like this. I has two child ComboBoxes and 50 Statics on it. I don't if I'm clearer now. I going to repost the questio
Alton Williams wrote:
On debugging what is causing the crashing seems lie with the first call to create for the first "window"
Seriously Alton, you have to investigate your own code better than that or no one will ever bother to answer your vague question. It's perfectly allright to have an ActiveX control as a container for another ActiveX control, you don't have to doubt that. The reason why this doesn't work in your code is because you've either removed some important stuff or haven't written the important stuff yet. It's also not very clear what base classes you're subclassing from or why. If you're using MFC to create your controls, the only class you should derive from is COleControl; anything else I would consider highly suspicious and to be removed at once if not given a lot of thought ending with "I've-read-alot-about-it-and-I-know-it's-the-correct-way-to-do-it". ;) I suggest you start over with the CHolderCtrl and create it with the ActiveX control wizard. For every step you take building the functionality of the CHolderCtrl, you should test it with "ActiveX Control Test Container" that ships with MSVC. Don't add the two contained ActiveX controls to CHolderCtrl until the last step. Make sure they can be inserted in an ordinary ActiveX control container before attempting to add them to CHolderCtrl.
Alton Williams wrote:
Its when I add HolderControl onto other projects I drag and drop it on a diaglogue box and crashes VC++
This feels like the ActiveX control hasn't got all the required interfaces implemented as needed for it to an ActiveX control container. Have a look here[^] for required interfaces depending on what functionality you want to support.
Alton Williams wrote:
MS Calendar Control 8.0 dosen't behave like this. I has two child ComboBoxes and 50 Statics on it.
Now, this sentence really disturbs me since it makes me wonder if you're under the impression that comboboxes, edit and static controls are ActiveX controls. :~ Just to tie up loose ends: com