• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 303
  • Last Modified:

Using an ActiveX control in a MDI application without having to open a seperate dialog or document (Urgent)

Hello everyone,
I have a MDI application that needs to use an ActiveX control that I made as well.  The ActiveX control does two things; number crunching and opens a its own dialog box if needed.  Using the control from a dialog box is no problem, but I am having trouble getting it to run anywhere else.  What I need to do is run the ActiveX control at statup, and preferably put it in the Main Frame class.

Is there a solution where I can get events and call methods from the ActiveX control with out having to open a dialog box first?  The best solution that I can come up with is to create an invisible dialog box to keep the control in, although I haven't tried it yet.

Thanks
0
bigsteve87
Asked:
bigsteve87
  • 3
  • 3
1 Solution
 
rcarlanCommented:
If your ActiveX doesn't display a child window when created/activated or if its functionality doesn't require one being displayed (which seems to be the case from what you're saying) you can place it in your main-frame without any problems. You will obviously have to create it manually - i.e. call Create on the CWnd-derived class generated by the VC++ IDE when you added the control to the project.

Radu
0
 
bigsteve87Author Commented:
Ok, here is what I've got
I add the Control to the project and am calling it from my dialog class like this:

m_pActiveXControl = new CActiveXControl;
m_pActiveXControl->Create("Active X Ctrl", WS_DISABLED, CRect(0, 0, 20, 20), theAPP->m_pMainWnd, 777);
m_pActiveXControl->DoWhatever( ):

Then I add the events, copying what the classwizard generates when I add them through a dialog class

BEGIN_EVENTSINK_MAP(CMyDocument, CDocument)
    //{{AFX_EVENTSINK_MAP(CMyDocument)
      ON_EVENT(CMyDocument, 777, 1 , OnWhateverEvent, VTS_R4)
   //}}AFX_EVENTSINK_MAP
END_EVENTSINK_MAP()

void CMyDocument::OnWhateverEvent(float fValue)
{
}

Everything is working fine until any function is called that opens a dialog box from within the ActiveX control
When that happens I start getting asserts from Wincore.cpp line 884, and my Events dont work anymore.
I am guessing that the problem is with the window that I use when creating this; theAPP->m_pMainWnd.
I tried putting everything in the CView class and using it's window, but was getting the same thing.

0
 
rcarlanCommented:
I was under the impression that the events sink needs to be in the parent window. I could be wrong, though.

Under what circumstances does your ActiveX display a dialog? Is the dialog displayed synchronously (e.g. as a result of a method call) or asynchronously (i.e. by another thread running in the ActiveX)? Is it a modal dialog or a modeless dialog?

Radu

0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
bigsteve87Author Commented:
The dialog is modal and displayed synchronously.
I needed to use it in the parent window to call only one method that does not display a dialog.  
Each document I open will create a control and use the events sink, and if possible have the ability to call a modal dialog through a method.
At first I was not completely sure of the layout, but after working with it more, this is what I came up with, sorry about that.
0
 
rcarlanCommented:
You obviously need to host the ActiveX in a window. With the design decision made above, it looks like you'll have to host the ActiveX in the view or its frame (not the main frame). If you have an MDI (which seems to be the case), you may end up with multiple views for each document (the MFC design certainly supports it, and there is a “New Window” command that, if exposed, will allow users to create a new view for the same document). You have to keep this in mind, because it may result in multiple ActiveX instances per document (i.e. one in each view).

Anyway, with the ActiveX in the view, you may have to place the events sink in the view also. As I said above, I believe the events sink needs to be in the parent window (i.e. the window hosting the ActiveX). However, this may not be the case - I'm not sure. Anyway, it seems cleaner to have the events sink in the view, as there may be many views per document (i.e. many ActiveXs per document). To play it safe, you may want to start with the events sink in the view anyway and run your tests like that. Once you get things working properly, you may try to move it to the document and test again.

If the ActiveX does indeed display a modal dialog as a result of a call to a method (i.e. synchronously), it means the method does not return until the ActiveX is dismissed. Is this what you have observed?

The failed assert seems to indicate that when it occurs, the code is somehow running a different thread than the main U/I thread that created the window in the first place. This shouldn't happen if the ActiveX displays a modal dialog and doesn't return from the method until the dialog is dismissed.

Does the ActiveX fire events while the modal dialog is up?

Radu

0
 
bigsteve87Author Commented:
When I call the method to display a modal dialog, the method does not return until the dialog is closed.
Events are supposed to be fired while the dialog is open.

Ok, attaching it to the view does seem to work.  I must have been using the creating it with the wrong window when creating it in the view earlier.
Thanks for the help Radu.
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

  • 3
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now