Forum

Hi,

I had my application running in V2.251(with the patch loaded) and I downloaded the latest version V2.26 yesterday and tried to compile it. It compiles OK but it gives ASSERT when I try to run the application. The problem is in occMgr.cpp file line # 460. Looks like it was trying to create a window for dialog box.

Earlier with V2.251, I had some problem closing down my MDI Child windows and was hoping the bug fix in V2.26 would resolve this issue but it got worse. Will email you the entire code if needed. I am pushed against the wall with the deadline...

Your prompt help is highly appreciated.

Saroj

 

 

Dear Saroj,

We cannot reproduce the problem you are reporting. Please send us your (test) project so that we can help you resolve the issue as soon as possible.

Hi,

Thanks again for such a prompt response.

I will definitely send you the source code but I am afraid that you might not be able to instantiate the Matrox ActiveMIL OCX in the project. That is where it fails. Matrox ActiveMIL has got strict protection system and it will not run without a developer hardware or runtime hard dangol.

Let me explain you the problem that I am having.

1.  I have a dialog box with one of their ActiveX control called ActiveMIL Display control. This control is used to grab a live video from the camera and disply on it. When I try to load the dialog in ONCreate() routine of Mainframe.cpp, it gives a ASSERT on the line marked in Red and Bold below. The code is as below:

#ifdef ACTIVEMIL_IN_PROJECT

if(!m_wndImageCapture.Create( _T("Image Capture Window"),

this,

ID_VIEW_CAPTURE_WINDOW

) )

{

TRACE0("Failed to create Image Capture Window...\n");

return -1; // fail to create

}

if(!m_dlgForImageCapture.Create( IDD_IMAGE_CAPTURE_DIALOG, &m_wndImageCapture) )

{

TRACE0("Failed to create Image Capture Window...\n");

return -1; // fail to create

}

m_dlgForImageCapture.ShowSizeGrip( FALSE );

m_dlgForImageCapture.SetOwnerAppSystemAndDigitizer(pApplication, pSystem, pDigitizer, blnOFFLineVersion);

// Set this window not to be visible in the right-click pop-up menu

m_wndImageCapture.m_bAppearInDockSiteControlBarPopupMenu = FALSE;

#endif

2. On my MDI Child window, I create the same OCX control and use it to disply the images captured. However, I create the control using the following lines of code and attach it with the View(this code is executed inside the DrawVW.cpp:

pApplication = ((CMainFrame*) AfxGetMainWnd())->GetApplication();<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

pDisplay = pApplication->CreateObject(_T("MIL.Display"), FALSE);<o:p></o:p>

if (pDisplay->DisplayType == dispDualScreen ||<o:p></o:p>

pDisplay->DisplayType == dispNonWindowed ||<o:p></o:p>

pDisplay->DisplayType == dispVideoEncoderNonWindowed)<o:p></o:p>

{<o:p></o:p>

SetMessage("This example does not run in dual screen mode.");<o:p></o:p>

return(FALSE);<o:p></o:p>

}<o:p></o:p>

// Set the owner system and the image of the display<o:p></o:p>

pDisplay->OwnerSystem = OwnerSystem;<o:p></o:p>

pDisplay->Image = Image;<o:p></o:p>

pDisplay->DisplayType = dispUserWindow;<o:p></o:p>

pDisplay->UserWindow = (long)m_hWnd;<o:p></o:p>

pDisplay->OverlayLUT->NumberOfBands = 3;<o:p></o:p>

// Allocate the display<o:p></o:p>

pDisplay->Allocate();

The code was working OK with earlier version of Prof_UI (V2.251) but when I try to close the MDI Child window, it used to give ASSERT and would never close. I thought it was a bug in the Prof_UI code because double-clicking on the upper-left box of an application used to give ASSERT.  Life is not easy...isn’t it ?

Any thoughts is highly appreciated. I will contact your technical support for further discussion and email you the sample project. Sorry for writing the entire story here. I thought some forum member would also benefit from the problem I am having.

Saroj

Dear Saroj,

There is only one requirement for using ActiveX controls in MFC projects: AfxEnableControlContainer() should be called when the applications starts(usually in the InitInstance method of any CWinApp-derived class). Windowed ActiveX controls are based on the HWND objects. So, perceive them just as ordinary windows with some API compliant to the COM/ActiveX standard. Please try to use some another ActiveX control in your project (instead of Matrox ActiveMIL). For instance, you may use the calendar control from Microsoft. Please let us know the result of this try or sent us the source code.

I may confirm that MDI works ok with all 2.25.x an 2.26 versions that I have. My app uses a lot of different kind of windows (including: MDI, page container, toolbars, menus, etc) and it all works.

May be MDI window is closed by a method other than MDIDestroy?..

Hi Dmitry,

I did some more debugging and found that when the MDI window is destroyed by clicking X on the upper-left corner, it actually calls MDIDestroy() function. However, Only the frame window is destroyed during this process but not the View. I had break-points at the destructor of Frame Window and the View. Only the destructor of the Framewindow is called when MDIDestroy() function is called.

I created a similar MFC application (with No Prof_UI) and it in fact goes to both of the destructor and it works well. Any idea why this is happening.

Appreciate your help.

Saroj

Dear Saroj,

We cannot confirm this bug. The MDIDOCVIEW sample application has the CChildFrame and CMDIDOCVIEWView classes with destructors. The destructors are always called correctly if you close the MDI child frame window with Ctrl+F4 keys, by clicking on the "X"-button or by double-clicking the system icon in the normal or minimized state, by clicking the "X"-button in the menu bar in the maximized state. We believe the problem hides somewhere in your app. Of course, you may send us any source code that demonstrates this problem.

Do you have OnDestroy handler for the MDI frame? Do you call parent class OnDestroy in it? If not, client will not be destroyed.

Hi Dimitry and Tech Support,

I do not have OnDestroy(0 function in the MDIFrame window but do I OnDestroy() function in my View window (which is derived from CScrollView). In fact my application is based on your DrawCLI sample application and additional code. The underlying structure for the application should be same. When the View is closed, OnDestroy() function of the View is called and it calls the CScroillView::OnDestroy() function....No suprises there !! 

As I said in my earlier post, I have a raw MFC MDI test application that basically does the same thing (except that the UI is very very ugly) and it gets closed normally. Both Frame destructor and View destructor are called. Only time I hae problem is when I used Prof_UI and Matrox ActiveMIL controls inside the MDIChild client area (See next para for further info) .

Matrox control has an option to disply the image on the floating window instead of in the client area of the view. I did change my code to do that and it works OK. The destructor of the View is called and window gets removed from the view. For obvious reason, I cannot let the window float. It should be displayed on the client area of the MDIChild. The following lines of code does the magic of using the view window for displaying the image on the clwint area instead of floating window:

pDisplay->DisplayType = dispUserWindow;

HWND hWndChild;

hWndChild = m_hWnd;

pDisplay->UserWindow = (long)m_hWnd;

Follwoing is the description from their manual about these settings. I hope it will help you find a source of the problem:

 

1.                  Display -> UserWindow<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

 <o:p></o:p>

Synopsis<o:p></o:p>

Returns or sets the user window used by the Display control for displaying the image. <o:p></o:p>

[Visual Basic]<o:p></o:p>

Syntax <o:p></o:p>

object.UserWindow [= Long]<o:p></o:p>

[Visual C++]<o:p></o:p>

Syntax <o:p></o:p>

object->UserWindow [= long]<o:p></o:p>

Type description<o:p></o:p>

A long value that specifies the hWnd of the control or form into which you want to display images. <o:p></o:p>

Remark<o:p></o:p>

This property is valid when the DisplayType property is set to dispUserWindow. <o:p></o:p>

2.                  Display ->DisplayType

 <o:p></o:p>

Synopsis<o:p></o:p>

Returns or sets the type of display. <o:p></o:p>

[Visual Basic]<o:p></o:p>

Syntax <o:p></o:p>

object.DisplayType [= DispDisplayTypeConstants]<o:p></o:p>

[Visual C++]<o:p></o:p>

Syntax <o:p></o:p>

object->DisplayType [= enum DispDisplayTypeConstants]<o:p></o:p>

Type description<o:p></o:p>

A DispDisplayTypeConstants expression that specifies the type of display. <o:p></o:p>

<TABLE style="mso-cellspacing: 1.5pt" cellPadding=0 border=0>
<THEAD>
<TR style="HEIGHT: 17.25pt">
<TD style="BORDER-RIGHT: #d4d0c8; PADDING-RIGHT: 0.75pt; BORDER-TOP: #d4d0c8; PADDING-LEFT: 0.75pt; PADDING-BOTTOM: 0.75pt; BORDER-LEFT: #d4d0c8; PADDING-TOP: 0.75pt; BORDER-BOTTOM: #d4d0c8; HEIGHT: 17.25pt; BACKGROUND-COLOR: transparent">

Value<o:p></o:p>

</TD>
<TD style="BORDER-RIGHT: #d4d0c8; PADDING-RIGHT: 0.75pt; BORDER-TOP: #d4d0c8; PADDING-LEFT: 0.75pt; PADDING-BOTTOM: 0.75pt; BORDER-LEFT: #d4d0c8; PADDING-TOP: 0.75pt; BORDER-BOTTOM: #d4d0c8; HEIGHT: 17.25pt; BACKGROUND-COLOR: transparent">

Meaning<o:p></o:p>

</TD></TR></THEAD>
<TBODY>
<TR>
<TD style="BORDER-RIGHT: #d4d0c8; PADDING-RIGHT: 0.75pt; BORDER-TOP: #d4d0c8; PADDING-LEFT: 0.75pt; PADDING-BOTTOM: 0.75pt; BORDER-LEFT: #d4d0c8; PADDING-TOP: 0.75pt; BORDER-BOTTOM: #d4d0c8; BACKGROUND-COLOR: transparent">

dispDefaultWindow <o:p></o:p>

</TD>
<TD style="BORDER-RIGHT: #d4d0c8; PADDING-RIGHT: 0.75pt; BORDER-TOP: #d4d0c8; PADDING-LEFT: 0.75pt; PADDING-BOTTOM: 0.75pt; BORDER-LEFT: #d4d0c8; PADDING-TOP: 0.75pt; BORDER-BOTTOM: #d4d0c8; BACKGROUND-COLOR: transparent">

Displays in the control’s own window. <o:p></o:p>

</TD></TR>
<TR>
<TD style="BORDER-RIGHT: #d4d0c8; PADDING-RIGHT: 0.75pt; BORDER-TOP: #d4d0c8; PADDING-LEFT: 0.75pt; PADDING-BOTTOM: 0.75pt; BORDER-LEFT: #d4d0c8; PADDING-TOP: 0.75pt; BORDER-BOTTOM: #d4d0c8; BACKGROUND-COLOR: transparent">

dispUserWindow <o:p></o:p>

</TD>
<TD style="BORDER-RIGHT: #d4d0c8; PADDING-RIGHT: 0.75pt; BORDER-TOP: #d4d0c8; PADDING-LEFT: 0.75pt; PADDING-BOTTOM: 0.75pt; BORDER-LEFT: #d4d0c8; PADDING-TOP: 0.75pt; BORDER-BOTTOM: #d4d0c8; BACKGROUND-COLOR: transparent">

Displays in a user-specified window. <o:p></o:p>

</TD></TR>
<TR style="HEIGHT: 16.65pt">
<TD style="BORDER-RIGHT: #d4d0c8; PADDING-RIGHT: 0.75pt; BORDER-TOP: #d4d0c8; PADDING-LEFT: 0.75pt; PADDING-BOTTOM: 0.75pt; BORDER-LEFT: #d4d0c8; PADDING-TOP: 0.75pt; BORDER-BOTTOM: #d4d0c8; HEIGHT: 16.65pt; BACKGROUND-COLOR: transparent">

dispExternalWindow <o:p></o:p>

</TD>
<TD style="BORDER-RIGHT: #d4d0c8; PADDING-RIGHT: 0.75pt; BORDER-TOP: #d4d0c8; PADDING-LEFT: 0.75pt; PADDING-BOTTOM: 0.75pt; BORDER-LEFT: #d4d0c8; PADDING-TOP: 0.75pt; BORDER-BOTTOM: #d4d0c8; HEIGHT: 16.65pt; BACKGROUND-COLOR: transparent">

Displays in an external window created by ActiveMIL. <o:p></o:p>

</TD></TR>
<TR>
<TD style="BORDER-RIGHT: #d4d0c8; PADDING-RIGHT: 0.75pt; BORDER-TOP: #d4d0c8; PADDING-LEFT: 0.75pt; PADDING-BOTTOM: 0.75pt; BORDER-LEFT: #d4d0c8; PADDING-TOP: 0.75pt; BORDER-BOTTOM: #d4d0c8; BACKGROUND-COLOR: transparent">

dispAuxiliary <o:p></o:p>

</TD>
<TD style="BORDER-RIGHT: #d4d0c8; PADDING-RIGHT: 0.75pt; BORDER-TOP: #d4d0c8; PADDING-LEFT: 0.75pt; PADDING-BOTTOM: 0.75pt; BORDER-LEFT: #d4d0c8; PADDING-TOP: 0.75pt; BORDER-BOTTOM: #d4d0c8; BACKGROUND-COLOR: transparent">

Displays the image without a surrounding window. <o:p></o:p>

</TD></TR></TBODY></TABLE>

 <o:p></o:p>

Remarks<o:p></o:p>

This property cannot be set at run-time if the control is in the allocated state. <o:p></o:p>

When dispDefaultWindow, dispUserWindow, or dispExternalWindow is specified, the overlay image allows the underlying image to be seen within a surrounding window. If the overlay image is moved, the underlying image follows the same movement. <o:p></o:p>

When dispUserWindow is specified, the UserWindow property must be set in code at run-time to specify the window to be used for displaying. <o:p></o:p>

When dispExternalWindow is specified, the ExternalWindow object can be accessed by the ExternalWindow property. <o:p></o:p>

When dispAuxiliary is specified, you must manage your own overlay window and fill it with the keying color in order to see the underlying image. The image is always displayed at the top-left corner of the screen. To display the image elsewhere, allocate a parent image that is the same size as the auxiliary screen’s display resolution and then allocate a child image, at the desired location, to display the underlying image. <o:p></o:p>

For all DisplayType settings, only one image can be displayed on a specific Display control at a time. Use child images to display multiple images. <o:p></o:p>

For each system that has been allocated, you can allocate and select up to a maximum of 64 windowed displays.

 

Child window may prevent parent from destroying. Probably you should destroy the control first and the OnDestroy handler of the view and then (important: *after* control is destroyed!) call CScrollView::OnDestroy

Hi Dmitry,

I tried deleting the object resources before calling the function CScrollView::OnDestroy() but it did not help. Please remember that the Control is using the Client Area window of the View for displaying the picture. That’s why there is no extra window to be destroyed.

Furthermore, I found that when this control is created and client window is used to display the picture, OnNcDestroy() function was not being called and CView was never removed from the list iof views where as the frame window was already deleted. I could successfully close the window by calling OnNcDestroy() function from my OnDestroy() function. Sadly, enough, it created another problem....When I close my MDI frame window, it gives ASSERT on the following line of the file wincore.cpp line # 1002:

 ASSERT(pMap->LookupPermanent(hWndOrig) == NULL);

This must be because the MDIFrame thinks that the window that was forced delete is still in it’s list of windows to be closed and deleted. I came to this conclusion because if I do not open any MDI Child windows, the frame window closes smoothly. Can you suggest a better way to force close the MDI Chuild window ?

Finally, I still believe that there is some problem with Prof_UI code for my application. If the same scenario is created using raw MFC, I do not get any error. I hope you will be able to track down the problem and get it fixed soon. Please let me know if I could be of any help. I will be glad to provide you more information.

I could even send you the MIL CD-ROM and a hardware dangol for your development along with my source code if you think that could make your side of debugging easier.

Thanks a lot for your help...I am going to try somethuing more and will let you know if I make any progress.

Regards,

saroj

Dear Saroj,

Could you send us this ActiveX object only. It should work even without required hardware. We wonder what’s wrong with it.

Hi Tech Support,

Your sample test application was running good. I modified and added my code into it and it still works OK. However, my application was compiled in UNICODE where as the sample app was in multi byte. When I switched the compilation to UNICODE for the sample application, I saw the same problem. Looks like there is some issue with UNICODE library.

For now, I am going to use MBCS settings and proceed with my development and I would like to switch to UNICODE one day for multi language support. Please let me know if any of this make any sense.

I cannot thank you enough for the superb support.

saroj

Dear Saroj,

The project we sent you uses the MBCS character system. To convert it into Unicode, just remove the _MBCS symbol and add the _UNICODE symbol in the preprocessor settings for all project’s configurations. Please also put the wWinMainCRTStartup text into the "Entry-point symbol" field of the linker settings for all build configurations.

Hi Tech support,

I already compiled your test application both in UNICODE and MBCS version. The problem is there only in UNICODE version where as it works OK in MBCS version. That is what I was trying to point out in my earlier post. I might not be very clear in the post. PLease let me know if it makes any sense...

Looking forward to your comment.

Saroj

Dear Saroj,

The problem may be caused by improper use of TCHAR-related preprocessor macroses in your project settings. You app should work both with Unicode and with MBCS. Could you send us your latest project version based on our sample template project?