Forum

Hi all,<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

<o:p> </o:p>

Is it possible I get the button ellipse event handle of a determinated cell grid when this grid is a simple variable member of  a MDI class, like CExtGridWnd m_grid;, or I need derivate it like: mygrid : public CextGridWnd and so override the event ?<o:p></o:p>

<o:p> </o:p>

Thanks,<o:p></o:p>

Hello...

Can I change the color of the control bar’s drag focus rectangle? Our users are disconviniened by this situation when dragging takes place over the MDI client area.

Thank You, Ruslan

Thank you for the interesting question. At the moment Prof-UIS does not provide the option of repainting the docking outline for the resizable bar being drag-and-dropped. We can implement this feature within a few days and provide you with a source code update.

Please note: Prof-UIS 2.26 implements the docking algorithm like in Visual Studio 2005 and there is no docking outlines at all.

Please let us know whether you need this feature.

We are very interested in this feature.

Thanks for support, Ruslan

We implemented this feature. Please take a look at this screenshot. Is it what you need? If so, we will send you an update.

Great thanks for quick and effective support! Your update works fine and looks good!

Ruslan

Hello...

How to display the string "Click Ctrl key to prevent docking" in status bar during control bar repositioning (Like Visual Studio 6.0)?

Thank You, Ruslan

The Click Ctrl key to prevent docking string is displayed automatically in the status bar’s pane whose identifier property is equal to zero. Prof-UIS automatically provides your apps with this feature. If you cannot see this string, then something goes wrong the status bar is initialized in your application.

If you need to set this text manually, then you may use the following method of the CExtControlBar class:

static void stat_SetMessageString(
   CWnd * pWnd,
   UINT nCmdID = AFX_IDS_IDLEMESSAGE
);

The pWnd parameter is your CFrameWnd-derived class, or any frame’s control bar, or any other window inside the frame. This method will automatically find the status bar and set the message loaded from the string table resource. The AFX_IDS_IDLEMESSAGE resource identifier corresponds to the standard "Ready string. The IDS_EXTSTATUS_PERVENT_DOCKING resource identifier corresponds to the Prof-UIS’s Click Ctrl key to prevent docking string.

I’m sorry, but any of Your samples doesn’t display this string. Does the status bar is initialized wrong in Your samples? Or what I need to do to properly initialize the staus bar?

Thank You, Ruslan.

You are absolutely right. The most samples do not display this string because they are linked to Prof-UIS statically. The "Hold Ctrl ..." string is loaded from the IDS_EXTSTATUS_PERVENT_DOCKING resource (Prof-UIS DLL resources). The IDS_EXTSTATUS_PERVENT_DOCKING constant is used as a WPARAM parameter of the MFC’s internal WM_SETMESSAGESTRING string that is handled by CFrameWnd to load an appropriate string and put it into the status bar’s pane whose identifier is equal to zero. So, we have no chance to use this string in apps statically linked to Prof-UIS. But you may copy this string into your app’s resources to let your frame window load this message successfully when any Prof-UIS control bar starts to be drag-and-dropped.

Thanks a lot. The problem was in static linkage, not in status bar’s pane identifier.

Hello...

In the help topic "How to insert menu items at runtime?" You say that "CExtPopupMenuWnd::g_nMsgPrepareMenu registered message... is generated each time any popup menu appears on the screen". But in my humble opinion this message is generated only for top-level popup menus. It is not generated for submenus. How can I insert items in submenu at runtime?

Thank You, Ruslan.

You are absolutely right. The CExtPopupMenuWnd::g_nMsgPrepareMenu registered windows message is sent for the entire menu tree. This mean you need to implement some recursive function that will be called from the message handler. It should traverse the menu tree and modify any menu item on any sublevel if needed. The "... any popup menu appears ..." phrase implies the entire popup menu tree.

LRESULT CMainFrame::OnExtMenuPrepare(
 WPARAM wParam,
 LPARAM lParam
 )
{
 lParam; 
 CExtPopupMenuWnd::MsgPrepareMenuData_t * pData =
   reinterpret_cast 
   < CExtPopupMenuWnd::MsgPrepareMenuData_t * >
   ( wParam );
 ASSERT( pData != NULL );
 CExtPopupMenuWnd * pPopup =
  pData->m_pPopup;
 ASSERT( pPopup != NULL );
 if( _DoMyMenuPrepare( pPopup ) )
  pData->m_bMenuChanged = true;
}
LRESULT CMainFrame::_DoMyMenuPrepare(
 CExtPopupMenuWnd * pPopup
 )
{
 // method returns true if pPopup items were changed
 int nCount = pPopup->ItemGetCount();
 for( int i = 0; i < nCount; i++ )
 {
  MENUITEMDATA & _mii = ItemGetInfo( ItemGetCount()-1 );
  if( _mii.IsSeparator() )
   continue;
  if( _mii.IsPopup() )
  {
   CMainFrame::_DoMyMenuPrepare(
    _mii.GetPopup()
    );
   continue;
  }
// HERE IS:
// please insert your initialization code for the pPopup
// sublevel’s commands
 }
}

Help.  I’m getting an assert when I try and create a dialog based on CExtResizableDialog...  CDialog does not exhibit this behavior.

For example

CMyDialog cDlg;

cDlg.DoModal();

From dlgcore.cpp line 436 (using v2.26 - vc++ 7.1)

430: BOOL CDialog::InitModalIndirect(LPCDLGTEMPLATE lpDialogTemplate, CWnd* pParentWnd, void* lpDialogInit)

432: {

433: // must be called on an empty constructed CDialog

434: ASSERT(m_lpszTemplateName == NULL);

435: ASSERT(m_lpDialogTemplate == NULL);

436: ASSERT(lpDialogTemplate != NULL);

438: if (m_pParentWnd == NULL)

439: m_pParentWnd = pParentWnd;

441: m_lpDialogTemplate = lpDialogTemplate;

442: m_lpDialogInit = lpDialogInit;

444: return TRUE; // always ok (DoModal actually brings up dialog)

}

 

Thanks for any help, - Bradley

We sent you an update that should resolve the problem by e-mail. We plan to publish this update within a few days.

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

I’ve noticed this behavior in my application and your sample apps.  If I double click in the upper lefthand corner of an application to terminate it, I get the following exception:

Debug Assertion Failed!

Program: ...\MyApp\MyApp Debug.exe File: C:\...\Prof-UIS Source\Src\ExtPopupMenuWnd.cpp Line: 8841

What can I do to avoid this exception?

Thanks,

*** Art Poley ***

Dear Art,

We have already fixed this bug and can provide you with the source code update via email.

Hi Tech support,

Can I also receive the fix for this bug. I currently have V2.251 and I still have this problem with my app. Please send me the code at sacharya03@yahoo.com.

Thanks, Saroj

Dear Saroj,

The new version, which includes MS VS 2005 GUI theme, docking markers, automation support and more, will be released very soon. We sent you a link to our ftp site for the registered users by e-mail.

I have an MDI application that contains a Dockable CExtTabPageContainerFlatWnd with three different tree controls.  I then have several Doc/Views available for manipulation of graphic objects.  The Mouse wheel event, ON_WM_MOUSEWHEEL, is used within my views to provide a mechanism for the user to zoom in/out.  What I’m noticing is whenever I manipulate/change focus to my treeview and then back to my CView the mousewheel event is no longer being delivered.  Each tree control is being created with the following:

 if( !this->Create(
  WS_CHILD|WS_VISIBLE|WS_VSCROLL|WS_HSCROLL|WS_TABSTOP
  |TVS_HASBUTTONS|TVS_HASLINES|TVS_LINESATROOT
  |TVS_INFOTIP|TVS_DISABLEDRAGDROP
  |TVS_SHOWSELALWAYS|TVS_TRACKSELECT,
  CRect(0,0,0,0),
  m_pTabsContainer,
  UINT(IDC_STATIC)
  )
  )

Any thoughts as to why?

Thanks in advance,

*** Art Poley ***

We frequently move several CExtToolControlBar bars around in our application.  With our debug version, we frequently hit the following ASSERT statement within the Prof-UIS libraries:

void CExtDockOuterBar::_AffixmentBringToTop( CExtControlBar * pBar ):

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

Line 5081: ASSERT( nWeight2 != nWeightX );

<o:p> </o:p>

<o:p>Why is this occurring?</o:p>

<o:p></o:p> 

<o:p>Thanks in advance,</o:p>

<o:p></o:p> 

<o:p>*** Art ***</o:p>

Hello...

The two methods CMainFrame have been shown in your samples : OnBarCheck and OnUpdateControlBarMenu. The current samples version has implementation like this:

void CMainFrame::OnUpdateControlBarMenu(CCmdUI* pCmdUI)
{
// CFrameWnd::OnUpdateControlBarMenu( pCmdUI );
 CExtControlBar::DoFrameBarCheckUpdate(
  this,
  pCmdUI,
  false
  );
}

BOOL CMainFrame::OnBarCheck(UINT nID)
{
// return CFrameWnd::OnBarCheck( nID );
 return
  CExtControlBar::DoFrameBarCheckCmd(
   this,
   nID,
   false
   );
}

As far as I understand this, there are two variants of the implementation for this methods. CExtControlBar-based implementation complies the VS.NET-like control bars.

First, as mentioned in Your help, in this case "no check marks and are only used to activate resizable control bars". But tooltips for this control bars are still "Show / hide xxx-bar". Can You correct this little mismatch?

The second is menu question from my email to Your support. My dynamic control bars are are fixed-size control bars, derived from CExtPanelControlBar. I don’t want to use registered icons for them. All I want is checked/unchecked icons such as "status bar" command have. What I need to do for that?

Ruslan.

 

Indeed if the auto-hide feature (with respect to the resizable control bars) is used in your app, then appropriate commands always display these bars and their visibility cannot be controlled. We will fix this in the next Prof-UIS release. If this problem is critical for you right now, we will provide you with the update in a few days.

As for the second question, if you allocate the command identifiers for your dynamic control bars in the command manager and do not assign icons to these commands, only check-marks will be displayed, which is exactly what you need. Please provide us with more details on how you implemented dynamic panel bars in your app or let us take a look at your source code.

Ok, tell me please when the menthoned release will be chiped?

Here are some parts of source code about second problem:

Suppose that

class CMainFrame : public CMDIFrameWnd
{

...
  typedef map <LONG, CExtPanelControlBar*> CDealControlBars;

 CDealControlBars     m_mapCP2DealDockedWnds;

...
};

This method creates dynamic control bars and corresponding commands from registry’s data:

void CMainFrame::LoadNonMDIDealWndsState(const CString& strLogin)
{
 if (!strLogin.IsEmpty())
 {
  try
  {
   CMemFile file;
   CTTApp* pApp = static_cast<CTTApp*>(AfxGetApp());
   CString strRegKeyPath = ...

   if (CExtCmdManager::FileObjFromRegistry(file, strRegKeyPath))
   {
    CArchive ar(&file, CArchive::load);

    int nCount = 0;
    ar >> nCount;

    LONG nCPID = 0;
    UINT nChildID = 0;
    CString strDealWnd((LPCSTR)IDS_DEAL_WINDOW);

    for (int i = 0; i < nCount; ++i)
    {
     ar >> nCPID;
     ar >> nChildID;

     CString caption;

     CExtPanelControlBar* pControlBar = new CExtPanelControlBar;
     pControlBar->m_bAutoDelete = TRUE;
     if( !pControlBar->Create(
       caption,
       this,
       nChildID,
       WS_CHILD
       |CBRS_LEFT|CBRS_GRIPPER|CBRS_TOOLTIPS
       |CBRS_FLYBY|CBRS_SIZE_DYNAMIC
       |CBRS_HIDE_INPLACE|CBRS_FLOAT_MULTI

       )
      )
     {
      CString strFormat(_T("CMainFrame::LoadNonMDIDealWndsState: Failed to create deal control bar, CPID is %d"));
      CString strMsg;
      strMsg.Format(strFormat, nCPID);
      ReportInternalError(strMsg);
      continue;
     }

     bool bSuccess = false;
     CDealView* pView = (CDealView*)RUNTIME_CLASS(CDealView)->CreateObject();
     if (pView)
     {
      CCreateContext context;
      context.m_pCurrentFrame = NULL;
      context.m_pCurrentDoc = NULL;
      context.m_pNewViewClass = NULL;
      context.m_pNewDocTemplate = NULL;
      context.m_pLastView = NULL;
      if (pView->Create(NULL, NULL, WS_CHILD | WS_VISIBLE, m_rcDealView, pControlBar, AFX_IDW_PANE_FIRST, &context))
      {
       pView->ModifyStyleEx(0, WS_EX_CLIENTEDGE, SWP_FRAMECHANGED | SWP_DRAWFRAME);
       m_mapCP2DealWindow.insert(make_pair(nCPID, pView));
       pView->SetCPID(nCPID);
       pView->Dock();
       bSuccess = true;
      }

     }

     if (bSuccess)
     {
      CExtCmdItem cmdBar;
      cmdBar.m_nCmdID = nChildID;
      cmdBar.m_sMenuText = _T(" - ") + strDealWnd;
      g_CmdManager->CmdSetup(
          __PROF_UIS_PROJECT_CMD_PROFILE_NAME,
          cmdBar,
          true,
          NULL);

      m_mapCP2DealDockedWnds.insert(make_pair(nCPID, pControlBar));
      pControlBar->EnableDocking(CBRS_ALIGN_ANY);
      m_ctrlBarChildIDGenerator.ExcludeValue(nChildID);
     }
     else
     {
      pControlBar->DestroyWindow();
     }

    }
   }
  }
  catch(...)
  {
  }
 }
}

And this method modifies "View" submenu of the main menu:

LRESULT CMainFrame::OnExtMenuPrepare(WPARAM wParam, LPARAM lParam)
{
 CExtPopupMenuWnd::MsgPrepareMenuData_t* pData = reinterpret_cast<CExtPopupMenuWnd::MsgPrepareMenuData_t*>(wParam);
 ASSERT (pData != NULL);
 CExtPopupMenuWnd* pPopup = pData->m_pPopup;
 ASSERT (pPopup != NULL);

 INT nReplacePos = pPopup->ItemFindPosForCmdID(ID_LIST_OF_ALL_BARS);
 if (nReplacePos >= 0)
 {
  VERIFY(pPopup->ItemRemove(nReplacePos));
  if (!m_mapCP2DealDockedWnds.empty())
  {
   if (pPopup->ItemInsert((UINT)CExtPopupMenuWnd::TYPE_SEPARATOR))
   {
    for (CDealControlBars::iterator bar_it = m_mapCP2DealDockedWnds.begin(); bar_it != m_mapCP2DealDockedWnds.end(); ++bar_it)
    {
     pPopup->ItemInsert(bar_it->second->GetDlgCtrlID()))
    }
   }
  }
 }

 return TRUE;
}

What I need to correct? Or You need more source code?

The source code you published here does not contain enough details on how dynamic panel bars are created. Several important things are missing. For example, what is m_ctrlBarChildIDGenerator and how does it work? Could you send us your source code? You may send only CYourApp, CMainFrame, CYourChildFrame, CYourView, CYourDoc classes and the project file. We will remove dependencies from the remained source code manually. This will let us help you much faster.

When a control bar is floating a double click on the title bar docks it on other applications, but not in prof-uis. If it is docked and you double click on the title bar it does float, as it should. How do I get double click to dock it when floating?

1) Events of CExtTabPageContainerWnd :
   How to get notification about which page got active recently, likewise if i want to hide and show certain toolbars according to the page viewed in this class.

2) CExtTabFlatWnd :
   This control doesnt work on CFormView, we can see, we can not select any Tab, neither there is way to receive any events.
   This control’s First Tab becomes invisible when we click 2nd Tab only first time in CView, from next time onwards it works.

3) CExHookSink:
    Class is missing in documentation

4) Suggestion:
    New Class CExPagedView which can be used in MFC with document/view architecture. CExPagedView must be able to create and hold, switch multiple Views derived from CView. Also it must have OnPageSelected function which can be overridden to get notification of current selected View.

5) Too Big Examples:
    To understand CExtTabPageContainerWnd, I had to read Page example almost 10 times to find out where control is created. Ideal example would be One Control with 2 child controls, here you have created N number of controls which takes so long to analyze.

6) Is it good trick to earn money?
    Is it your policy to force users to come back to you for support? not provide proper and complete documentation? If that is the case, I would have searched number of code websites, get one one code from there and integrated it if I had to spend time to go through each and every forums etc. I thought I will get nicely MSDN sort of documentation which would contain everything!!!

I have a problem with tooltips for ComboBoxes on a toolbar.   They don’t appear even though I have verified that the tool string is associated with the command item, and that the activate message is sent to the tooltip control.

Actually, I see the same behaviour for your ProfStudio sample program.  For example the URL combobox on the Web toolbar doesn’t show a tooltip.

Is this intentional?

Thanks in advance

Finn Arildsen

MFC asserts inside DDX_Radio on the line that says:

ASSERT(::SendMessage(hWndCtrl, WM_GETDLGCODE, 0, 0L) & DLGC_RADIOBUTTON);

and skips all other radio buttons because they also do not return DLGC_RADIOBUTTON. I checked ExtButton.cpp, PresubclassWindow clears type styles and Windows cannot return proper control code...

Please, fix this in the next release.

Button does not become checked in a call to SendMessage(hWndButton, BM_SETCHECK, 1, 0)... I fixed the previous problem but DDX_Radio still does not work.

How would one provide an option that allows users to reorder the MDI tabs for all open documents.  I would image you need to change the z-order of the windows with the SetWindowPos API.  Would the tab control update to reflect the changed z-order?  Is there a better method for accomplishing this?

I’d like to see a drop and drop interface added to the tab control that allows the user to reorder tabs graphically (simliar to Avant and Maxthon browsers).

Dears,

I´m using profUIS-Controls sample application as base for developing my application.

In CPageTabContainers, I would like to know how can I hold event click in pages under CMyTabPageContainerWnd, to control behavior of CMyTabPageContainerWndFlat.

Thanks,

Luis

Hi,

I have a problem with CExtLabel.  The text in all of my CExtLabel controls appear with strikethrough (and sometimes also underlined).  This doesn’t happen for texts in any other control in my application.

When I simply replace CExtLabel with CStatic, the text appear properly.  

I have tried various things to pinpoint the reason for this problem, including a brute force SetFont call for the object, but to no avail.

I hope you can tell me what I do wrong.

Thanks in advance

Finn Arildsen

 

...after installation of a 2.25.1 patch. I opened Prof-UIS project in VC and made a clean build of all Prof-UIS libs. Problem with CExtLabel disappeared.

Actually I wondered why patch setup did not recompile libraries...

Neither the full library setup nor the patch "knows" which library configuration you really need. Besides, if we completely rebuild all library configurations, it will eat tens of gigabytes of the disk space. That is why the automatic library build is not performed by installation programs.

Hm, but setup program for the "normal" version has an option to build libraries. At least it was so in the previous version...

Dear Finn,

We have not yet encountered such a bug. Of course, we are very interested in helping you and clarifying what causes the problem. Could you let us take a look at your sample project?

Thanks for your very swift response.   I’m actually working on conversion of a 100K lines project, so it’s not straightforward for me to extract a sample project.

However, I’ll see if I can recreate the problem in a sample project.  This will be in a couple of weeks, though, due to other obligations. 

BTW, what governs a CExtLabel’s use of fonts?   Is there anything I may have touched that I shouldn’t have ?  (Not that I think I have intentionally touched anything wrt fonts).

We have no idea why the label’s font is damaged but you can find it out yourself by debugging the CExtLabel::OnDrawLabelText method’s code. You need to see which font is used for painting the text and why it is striked out and/or underlined.

I am having strange problem with my project. I have installed the V2.25 latest patch and use VC++ 7.10.

I get assert ERROR in the follwoing line of the code (file is winfrm.cpp). This happens only if I create certain COM Objects in my project. There is a function in my code to instantiate these COM objects. If I bypass these lines, I see no issues . Any idea where it is coming from ?

Thanks in advance.

 

Saroj

BOOL CFrameWnd::LoadAccelTable(LPCTSTR lpszResourceName)

{

ASSERT(m_hAccelTable == NULL); // only do once

ASSERT(lpszResourceName != NULL);

HINSTANCE hInst = AfxFindResourceHandle(lpszResourceName, RT_ACCELERATOR);

m_hAccelTable = ::LoadAccelerators(hInst, lpszResourceName);

return (m_hAccelTable != NULL);

}

Function to instantiate the COM objects....

BOOL CMainFrame::InitializeVisionSystem()

{

HRESULT retVal;

try

{

// Initialize the COM library

// retVal = CoInitialize(NULL);

// if( !((retVal == S_FALSE) || (retVal == S_OK )) ) // If not previously initialized or Initialization fails,

// return(FALSE); // return FALSE

retVal = pApplication.CreateInstance(_T("MIL.Application"));

if(!ErrorDescription(retVal))

return(FALSE);

pSystem = pApplication->CreateObject(_T("MIL.System"), FALSE);

pDigitizer = pApplication->CreateObject(_T("MIL.Digitizer"), FALSE);

pDigitizer->OwnerSystem = pSystem;

if(blnOFFLineVersion)

pSystem->SystemType = _T("VGA");

else

pSystem->SystemType = _T("Meteor_II");

pSystem->Allocate();

Wait(1000);

// Only allocate the digitizer if it is supported

if ((pSystem->NumberOfDigitizers != 0) && (!pDigitizer->IsAllocated))

{

pDigitizer->Allocate();

}

pImageProcessing = pApplication->CreateObject(_T("MIL.ImageProcessing"), FALSE);

pImageProcessing->OwnerSystem = pSystem;

pImageProcessing->Allocate();

}

catch(COleDispatchException* pException)

{

CString CErrorMessage;

CErrorMessage = pException->m_strDescription;

CErrorMessage = CErrorMessage + _T("\n");

CErrorMessage = CErrorMessage + pException->m_strSource;

AfxMessageBox(CErrorMessage, MB_OK, 0);

pException->Delete();

return(FALSE);

}

catch(...)

{

CString CErrorMessage;

CErrorMessage.LoadString(IDS_UNHANDLED_EXCEPTION);

AfxMessageBox(CErrorMessage, MB_OK, 0);

return(FALSE);

}

return(TRUE);

}

 

 

Didn’t you forget to call something like CoInitialize, OleInitialize, or AfxOleInit? This is usually placed in the InitInstance virtual method of your CWinApp derived class.

Hi,

I have tried calling CoInitialize(NULL) from the same function but it does not change anything. I will try OleInitialize() or AfxOleInit() from InitInstance() and see if solves the problem.

Another thing I noticed was that when LoadAccelTable(..) function is called, the value of m_hAccelTable is already something. It means the variable has already been initialized. Microsoft code also says...call it only once. Any idea why LoadAccelTable(..)  might be called twice ?

   ASSERT(m_hAccelTable == NULL); // only do once

Appreciate your help and support.

Saroj

 

The LoadAccelTable API should really be called only once. We suppose the error is somewhere in the CMainFrame::OnCreate method in which you may use an invalid initialization sequence for Prof-UIS-related features. Please pay attention to this method and look at how it is implemented in Prof-UIS samples.