Forum

I have the control bar stuff saving and restoring OK but I’d also like to be able to have it automaticallly re-open all documents that were open (to make this easy) when the app is shut down. So I need to save the filename, and the windowplacement stuff for all currently open docs. When the app next starts up I want to restore the main frame and control bars, along with re-opening all of the documents including internal window placements that were open at the time of the save. Is there an example flying around or a search on the KB here that I buggered up? I wasn’t able to find anything obvious while trying searches.

If there isn’t an app, where would be the best place to add this in?

The dynamic resizable control bars is a ready-to-use solution in your case. These bars are instances of the CExtDynamicControlBar class or derived from it. All the dynamic bars in the main frame window are managed by the instance of the CExtDynamicBarSite class. Typically CMainFrame is derived from the CExtDynamicBarSite class. The CExtDynamicControlBar bar windows has acts like older CExtControlBar bar windows. But dynamic bars have one additional "Options" button which looks like a drop-down arrow and displays a menu for switching bar’s state. The dynamic resizable control bars are able to switch into the constantly floating state, float inside MDI client area in MDI applications and switch into the tab page mode in SDI applications which use the Prof-UIS tab page container window as the main view window.

You can change the design of your application and use dynamic resizable control bars both instead simple resizable control bars and classic view windows. All the windows in your application will be created as children of dynamic resizable control bars. Some of them can initially appear in the dockable mode and look like resizable control bars. Some other can appear inside the MDI client area and look like MDI child frames. The state of all the dynamic resizable bars will be saved/restored by the dynamic bar site. All the bars inside the MDI client area can also become restored.

There are several sample applications dedicated to the dynamic resizable control bars. Please take a look at MDI_DynamicBars. It creates 40 dynamic resizable bars with the colored edit control inside each of them. You can see both dockable bars and bars inside the MDI client area. The state of all bars is restored and the background color of the edit windows inside each bar is also restored. The edit control’s background color is saved/restored as the part of its dynamic resizable bar’s state. You can also save restore any your specific data for each of your windows inside dynamic resizable control bars. This requires you to code your own CExtDynamicControlBar-derived class responsible for saving/restoring any custom data related to the window inside the bar. In case of colored editor container bars in the MDI_DynamicBars sample the CSimpleControlBar class performs background color serialization in the OnSerializeDynamicProps() overridden virtual method. Your dynamic resizable control bar should save/load the file name and other document properties.

It would be nice to store this in some XML style format instead of the mystery goo that gets stored in the registry somewhere - along with being able to switch between HKLM and HKCU.

Hi again

 

i recompiled the project to use profuis and mfc from dll and works.

Unfortunately i need to use static link

 

regards

George

Hello,

I experiment similar problems with 2.51 version (static build) : assertion failed while using the g_PaintManager object, but this occurs BEFORE any explicit call to the Prof-UIS library (between the constructor of the CWinApp derived class - with no call to Prof-UIS - and the call of the InitInstance() method.

The 2.52 version seems to solve this but present other problems :

- assertion failed while using the SetBasicCommands of menus (this can be overcome when disabling the expandable menu feature : also encountered with the 2.50 version, and it worked fine with the 2.42)

- if I tear the control bar off the frame, it can’t be docked again since the docking outline is not drawn any more, and it remains floating.

I need the static build, so the only solution to have the application working correctly was to revert to the Prof-UIS 2.50 version (without expandable menus).

Besides these temporary problems, I find Prof-UIS very useful !

Best Regards,

Christophe Guibert

We guess you just have not noticed some improvements which we made in the static LIB Prof-UIS version introduced in 2.52. The static library now has exactly the same features as the DLL version. All the Prof-UIS features are now available in the applications based on statically linked Prof-UIS. You can use customizable toolbars and menus, dynamic resizable control bars, icon editor dialog and other resource-dependent features. This allows you to hide Prof-UIS inside your application completely. Just make a small change in the .RC2 file of your project:

#if ( !(defined _AFXDLL && !defined __STATPROFUIS_WITH_DLLMFC__) )
    #include <Resources/Resource.rc>
#endif

You also need to specify the .../Prof-UIS/Include folder in the Additional Include Folders list of the resource compiler. This will include Prof-UIS resources into your application. All the static configurations of our sample projects are now based on this rule and they have no problems at run time.

Hello,

Good guess ! I understand now how the lack of binary resources added in the .rc2 file could lead to all the problems I encountered.

This was not obvious to find in your documentation, and I thank you for the quick and accurate answer. All is correctly working now with the 2.52 Prof-UIS version.

Best Regards,

Christophe Guibert

Hi,

Have you in plannig to create/release a control that implement TreeList features with your gui style?

thanks

We would also like to draw your attention to the tree grid control available in Prof-UIS. It is implemented in the CExtTreeGridWnd class derived from CExtGridWnd. The tree grid seems to be the window you are looking for. It is absolutely similar to CExtGridWnd but additionally supports a tree-like layout in the vertical direction. The CExtTreeGridWnd class defines its own API for accessing grid cells. All the methods are using zero-based column indices and HTREEITEM row handles. Please download and take a look at this sample, which deals with the CExtTreeGridWnd class. A set of toolbar buttons in this sample is defined to perform all the possible operations with the tree row structure in the tree grid window.

Is there an example to use this controls?

thanks

Please don’t consider the reply above ...

Hi all,

I see the DRAWCLI sample to add the "custom site" functionnality to my application.

All of my resource identifier are correct (controlled with Resource Organizer by Riverblade).

But many assertions apperas when I call the function :

VERIFY(CExtCustomizeSite::MenuInfoAdd(this, _T("Default"), IDR_MAINFRAME, true, false, RUNTIME_CLASS(CMainFrame)));

The text on the output window is :

Warning: Cannot load CExtCustomizeCmdTreeNode from archive. Class not defined.

CArchive exception: badClass.

First-chance exception at 0x77e9bc3f in MyProg.exe: Microsoft C++ exception: CArchiveException at memory location 0x0012f048..

And Visual Studio stops execution at the function :

CExtCustomizeCmdTreeNode * CExtCustomizeCmdTreeNode::CloneNode()

How can I correct this ? (I’m using Prof-uis 2.52 full edition)

Thanks a lot.

 

DrawCli is a customizable application, so, if you changed some toolbars or menu bars you need to clear the registry data (relating to this sample) so that the changes take effect. In your case, the application reads data describing the menu bar items from the registry and tries to apply these data to the initial menu bar which, in fact, is already changed by you and the changes cannot by applied.

What changes of my menu bar do you think about ?

The error occur when the first load of my application. After calling MenuInfoAdd, MenuInfoLoadAccelTable, EnableCustomization, ..., I call the

CExtCustomizeSite::CustomizeStateSerialize(ar) function.

But the program stops on the first function called (MenuInfoAdd). When DRAWCLI is started for the first time, there is no information on the registry.

My application use files to store UI information. Does the customization working only with the registry ?

Can you send me a sample (more simple than DRAWCLI) with customization and UI state stored on a single file ?

Regards,

Simon DESEE

Could you let us take a look at the entire call stack window. We know the assertion may occur even in 2.52 if you are using Prof-UIS as a static library and your project has some variables of Prof-UIS classes defined globally. In this case, these variables must be initialized before the g_PaintManager global variable is initialized in Prof-UIS. This may explain the errors like described in your message. Please check this issue.

How can I force the menu to use the icon 16x16.

I have 2 toolbars one 16x16 for the menu and one 32x32 for the application.

the flag CExtPopupMenuWnd::g_bMenuLargeIcons = false; has no effect.

is there a way to do this as the CmdManager handle only one icon for one ID ?

Thanks for any help.

I’m here with a one million dollar question...

Recently I posted in General Forum if there is the possibility to insert a dialog box in a cell, because I need to simulate the "continuous form" that we can found in Access.. I made it with a Grid control founded on www.codeproject.com, but now I wish to implement it with your grid control, that is more robust and looking better..

How can I do it?

Thanks in advance.

Paolo

OK, we would try to do this for you but we wonder whether you are satisfied with the quality of dialogs inside the grid window you saw on the codeproject?

We can really inject persistent HWND elements like dialogs into our grid window, but in any case they will produce some bad effects like a bit delayed repositioning during scrolling and etc.

Sorry for my question...

I face some problems with the project I’m doing now, and my goal was to, as I said, simulate the Access-like "continuous form".
 The grid I saw on codeproject satisfied me, but whereas there was no cell coded to accomodate a dialog box, I coded a cell for this purpose (the code is not so clean or perfect, but is quite accettable, specially for tmy customers’ needs, and it works).
The project is still under development, and I haven’t so much time to code a cell whit this behaviour; my question was intended to ask you if you faced yet this problem and was resolved, or if this was a completely new problem..
If this solution requires too much effort, no problems; I’ll continue this project with your grid and cells, and I’ll find another method to simulate the behaviour required; in any case I’ll plan to code a "dialog-cell" in the early future.

Thanks
 Paolo

The form editor and report editor windows are very similar to each other in MS Access. Both of them are not a kind of grid window. They are form editors written from scratch. The FormEditor sample application implements the simplest possible dialog editor which is something close to the editor of one band in the form or report of MS Access.

In some particular applications it’s possible to replace such kind of forms or reports with the grid window. We think our grid is ready for this task because it has a set of cell classes for most of cases. The dialog cell idea is not correct because the dialog window eats at least one window handle. There must not exist any per-cell window handles in any kind of the grid control. The cell may "eat" window handle(s) only when the in-place cell editing control is activated. Could you and we together try to review your form/grid design and reinterpret each dialog as a set of cells in one or more grid rows?

Can I send you an image that show actual behaviour of my "dialog-cell", so we can have a common starting point to discuss this problem?

Hi! Happy New Year to all of you!

In a thread on the 19th of December, 2005 you stated that ProfUIS v2.52 would be available in a few days. Could I ask again about the date we could download it? Thank you: Chris.

Hi,

One question about CExtGridCell.. Can I insert a CExtButton in a CExtGridCell?

Thanks, Paolo

 

The CExtButton class is a component that is based on a HWND window handle. The CExtGridCell class is a non-window component. So, it is not possible to insert windows into grid cells. But we can send you a sample application that demonstrates how to code a grid cell which looks and acts exactly like the push button.

Thanks.. this is exactly what I need!

Paolo

Hi, Happy New Year to all of you!

If you don’t have my email to send me the sample application, it’s the following: p.giustinoni@speedware.it

Thanks.

Paolo.

We wish you a very Happy New Year too. We have just sent the sample in question to the address you specified.

Would it be possible to get this sample emailed to me as well?

aspring@railcomm.com

We have just sent the sample in question to the address you specified. The sample project includes the source code for the CMyStartStopCell. This class implements a grid cell that acts like a button.

Can you send me the sample too.

My address: ckr@imab.tu-clausthal.de

Hello,

My application uses Prof-UIS 2.51 linked dynamically.

I’ve an extension DLL (using Prof-UIS 2.51 and MFC linked dynamically) who export a function that show a CExtResizablePropertySheet. In this function, I want to draw my dialog with propertysheets with the same theme than the applications’s theme.

Before creating my propertysheet, i’ve got an error when calling the InstallPaintManager function.

The error occurs on the function:

bool CExtPaintManager::CExtPaintManagerAutoPtr::InstallPaintManager(CExtPaintManager * pPaintManager)

who call

void CExtControlBar::PmBridge_OnPaintManagerChanged(CExtPaintManager * pGlobalPM)

The ASSERT_VALID( this ); break execution of the application.

Where the problem come from ? Does my application need to use MFC linked dynamically too ?

Thanks

We confirm that this is a bug. To get a bug-free version, Please contact us by e-mail.

Hi!

I’d like to change the caption of my controlbars dynamically, as a response of a menucommand. SetWindowText works fine for all controlbars except for those in document-state. I haven’t found any method for setting __EBCT_DOCUMENT_CONTAINER_CAPTION, only for getting it (OnGetBarCaptionText()). I could work around the problem with the following code:

bool bVisible;
if (m_pwndMyBar->BarStateGet(&bVisible) == CExtDynamicControlBar::__EDBS_DOCUMENT) {
  m_pwndMyBar->BarStateSet(CExtDynamicControlBar::__EDBS_DOCKED, true);
  m_pwndMyBar->SetWindowText(strNewCaption);
  m_pwndMyBar->BarStateSet(CExtDynamicControlBar::__EDBS_DOCUMENT, bVisible);
}

, but this causes an ugly flickering. Isn’t there a better solution for this problem? Or maybe this is also solved in your new versions (we’re still using 2.43)?

Thank you for your help! Have a merry and restful holiday (as much as it is possible:))!
Chris.

The caption text computing mechanism for the control bar now works absolutely like as in 2.43. So, please use the following code:

 
m_pwndMyBar->SetWindowText( strNewCaption );
if ( m_pwndMyBar->BarStateGet() == CExtDynamicControlBar::__EDBS_DOCUMENT )
{ 
    HWND hWnd = m_pwndMyBar->OnQueryChildHWND();
    ASSERT( hWnd != NULL && ::IsWindow( hWnd ) );
    hWnd = ::GetParent( hWnd );
    ASSERT( hWnd != NULL && ::IsWindow( hWnd ) );
    CWnd * pWnd = CWnd::FromHandlePermanent( hWnd );
    ASSERT_VALID( pWnd );
    CMDIChildWnd * pFrame =
        STATIC_DOWNCAST( CMDIChildWnd, pWnd );
    pFrame->SetTitle( strNewCaption );
}

Hi!

This does not work for me:( At the line "CMDIChildWnd * pFrame = STATIC_DOWNCAST( CMDIChildWnd, pWnd );" I get an assertion, because at that point pWnd points to my view, which is of CExtTabPageContainerWhidbeyWnd class that cannot be converted to CMDIChildWnd.
Which other class should I use to call SetTitle then?

Thank you: Chris

Hi,

Is it possible to dock Toolbars on the same row as the Menu Bar? This would be a useful feature.

Merry Xmas to all, especially Sergiy and everyone at Prof-UIS. I hope that 2006 is a great year for us all.

Neville Franks, www.surfulater.com 

I was using code taken from some of the samples (I started somewhere around 2.30 or so), and the __EXT_DEFAULT_CHECK_BOX_SIZE constant was used there. I installed 2.51 and when building my code, the compiler complains about it not being defined.

I could of course redefine it, or use its value (13 as defined in the previous packages), but is there a recommended way to change the code? Here is how it has been used:

CExtImageList il(m_nBitmapResource, RGB(255,0,255), __EXT_DEFAULT_CHECK_BOX_SIZE);

So I’ve subclassed CExtGridCellString, and when the cell is created, I want to call a member function in it to set some property. The idea is that when the cell is eventually clicked, I can access this exact property.

For example, I want to create a new DonutCell. When I create this DonutCell, I need to pass the DonutShop that created it. When this cell is clicked, the OnButtonPressed() method should be able to determine which shop created it.

When I step through my code, which looks like this:

DonutCell* pCell = DYNAMIC_DOWNCAST( DonutCell, ValueActiveGet());
pCell->SetDonutShop( "Krustys Donuts");

pCell is something like 0x4809578. When I click on the cell and hit my breakpoint in OnButtonPressed(), the this pointer is 0x481b968. Can you explain why it is that the active cell isn’t the same as the one that handles this message? I’m confused.

Ah, my colleague told me that it’s probably because stores get combined. So when I click on that cell, I’m getting a cell from the combined store. So the question is, if cell contents are copied, why isn’t my member variable (a pointer) being copied as well?

Each CExtPropertyValue instance keeps two CExtGridCell objects: the active one and the initial one. The later is used for the reset operation. These objects never appear inside tree grids in the property grid control and are stored inside CExtPropertyValue only. Each tree grid window in the property grid control contains the cloned copies of active grid cells in property values. That is why you faced different cell copies. When the editing is completed in some tree grid window, the property grid control assigns a new cell value to the active cell in the property value and to the all cells of this property value in other tree grid windows. In case of using combined property stores, each property value is a reference to several simple property values and the result of editing is assigned to all the referenced property values. So, if you use your own grid cell class which contains its specific data members, then it is important to override the CExtGridCell::Assign() virtual method like as follows:

void CYourCell::Assign( const CExtGridCell & other )
{
    ASSERT_VALID( this );
    CBaseCell::Assign( other );
CYourCell * pCell =
        DYNAMIC_DOWNCAST(
            CYourCell,
            ( const_cast < CExtGridCell * > ( &other ) )
            );
    if( pCell != NULL )
    {
        // assign all the specific data members
    } // if( pCell != NULL )
    else
    {
        // clear all the specific data members
        // like your did in constructor
    } // else if( pCell != NULL )
}

Hello

I am deriving a class from CExtDynamicTabbedControlBar in order to remove the "X" button and prevent floating of a control bar that contains two tabbed control bars. Obviously I can not do this with static linking. Is there a way around that? I don’t want to give up static linking just for removing the "X" button and prevent floating. Is it dangerous just to "undef" __EXT_MFC_NO_DYNAMIC_BAR_SITE? Obviously it is no problem to statically link to have the control bar WITH the "X" button so it must be possible to have that control bar WITHOUT that "X" button.

Thank you very much

Thomas

 

We faced the same behavior in the application of one of our customers. It appears only if the menu bar is not enabled for drag-and-drop-based re-docking. Unfortunately we failed to reproduce this bug in any of Prof-UIS samples. That problem has been temporarily solved by handling the CExtPopupMenuWnd::g_nMsgPrepareOneMenuLevel registered message and finding the menu item with the AFX_IDM_FIRST_MDICHILD identifier, removing all the items in the range of AFX_IDM_FIRST_MDICHILD .. (AFX_IDM_FIRST_MDICHILD+9) and inserting a single copy of window list commands.

It would be perfect if you would help us find out what’s wrong with the MDI menu. We would appreciate if you send us a "stripped" but fully functional version of your project which demonstrates the bug.

Please disregard the message starting with "We faced the same behavior...". We mistankely posted it to this thread.

Hello

I found the solution myself: It is sufficient to derive from CExtDynTabControlBar instead of CExtDynamicTabbedControlBar. Seems to work fine.

Thomas

 

I have a window that utilizes a custom paint routine to draw network elements with connections and background pictures. The elements can be dragged around, and the movement is displayed in realtime. To optimize speed, only the needed portion of the window is redrawn. After I changed the dialog to be derived from CExtNCW<CExtResizableDialog> (previously is was derived from CExtResizableDialog), there is some serious performance issues when dragging elements around inside the window.

In which way the drag-and-drop feature is implemented in your application? Is it based on the OLE drag-and-drop or on the image list? In any case, the drag-and-drop of any item from the list view, tree view or other control should not depend on the skin. It is not good idea to implement drag-and-dropped images on the dialog background because it may have an absolutely different color schema in different skins. Please provide us with more details on these questions.

It is not based on either OLE or image list. No windows or MFC controls are used whatsoever. The OnPaint routine paints the background and the objects. When an object is moved (OnMouseMove), the necessary window portions are invalidated with InvalidateRect. It seems to me like the complete window is repainted each time when I use skins. This could explain the performance issue.

The skin is based on the stretched bitmap output which is based on the StretchBlt() and AlphaBlend() APIs. We always tried to avoid using these APIs because they are well know as not fast enough but it is not possible to avoid using them when painting the skin. This is really the top reason of why the skin cannot be so fast as non-skin themes. In any case, we will check the region clipping issues while painting as you advise us.

The skin sample has "serious" performance issue here on my computer, it take roughtly a bit less than 1 sec to change menus from "color controls" to "Input Fields" and so on, the resize of the main window is also slow.. although the office themes are nealry realtime responsive.

Thank you

 

I have a tool window (tool window property is true) derived from CExtNCW<CExtResizableDialog>. This is not displayed correctly. The window caption is not any smaller than a regular window, and the close button is not highlighted when hovered.

This bug still exists in 2.83.  Is it fixed in 2.84?

Hi!

We have Prof-UIS v.2.43 installed and we decided to upgrade to v.2.51 because of some bugs preventing us from going further in our development. What are the main steps for upgrading? We have VS2003 installed. I’ve read in version history that your new help file is integrated with the Visual Studio Combined Help Collection. Do we have to use 2.50 installation package then? If so, do we have to uninstall v.2.43 before? And after installing v.2.50, should we just simply overwrite all source files with the ones found in v.2.51 zip file and recompile prof-uis.lib?

Thank you for your help!
Chris

P.S.: I know I’ve asked this several times already, but is there an approximate date when customization with statically linked library will be avaliable? We would really need that. Thanks.

Prof-UIS 2.51 has many new features and the help integrated with VSCHC, so to upgrade to the new version sounds reasonable. Please note that Prof-UIS 2.51 is an intermediate release, so the help remains the same as in Prof-UIS 2.50.

First, you need to uninstall the previous version. Then you can follow the steps your described yourself. Or you can just run the installer for 2.51 (we just made it available for download from the download page. After installing the library, please run the Integration Wizard.

As for the customization availability in the statically linked library, we have already done this but there is some final testing left to be done. So, this will be available in Prof-UIS 2.52 and, by adding one line of code, you will be able to make the Prof-UIS resources available in your statically linked application. We plan to finish up this testing in a few days and will notify you about that as the code is available for download.

MAYBE THIS WAS POSTED BEFORE BUT I DID NOT SEE IT IN THE FORUM SO I REPOST

Hello

I have a tabbed MDI application. Since I need to control the tab captions myself I derived a class CMyExtTabMdiWnd from CExtTabMdiWnd and implemented CMyExtTabMdiWnd::OnTabWndQueryItemText. I think that leads to my problem that in the "Window" menu only the accelerator numbers "1   ", "2   " are displayed.

There is a screenshot under

http://www.ierax.removeme.ch/download/mdiwindow.jpg

 

(remove "removeme.")

I would like my tab captions to appear in the Window menu. What am I doing wrong?

Thanks

Thomas

 

 

T

CExtTabMdiWnd

We need more details about your project. First of all, whether the CExtMenuControlBar window is enabled for the drag-and-drop-based redocking or not? We also need to know whether the MFC’s document view architecture is used. Finally, if it is possible to let us take a look at your project, then please send it to us. This would let us analyze your UI initialization code and avoid making a guess.

Hello

Thank you for your reply. I can not send you the whole project but I can give you the key sources where the Prof-UIS stuff is in.

Please download from http://www.ierax.removeme.ch/download/veprofuis.zip (please remove "removeme.")

I am NOT using the doc/view architecture of MFC

I guess there is not much to say to CMainFrame. You will find your way around that one.

The constructor of CVEDocument contains the code to create a child frame.

CChildFrame contains the child frame code.

I will gladly answer any questions if you need further information

Thank you

Thomas

You should not use the CFrameWnd::EnableDocking() method with Prof-UIS control bars. Please use the CExtControlBar::FrameEnableDocking() method instead. So, just find the following line in the CMainFrame::OnCreate() method:

EnableDocking(CBRS_ALIGN_ANY);

and replace it with the following code:

if( ! CExtControlBar::FrameEnableDocking(this) )
{
     ASSERT( FALSE );
     return -1;
}

This is the single error we managed to find but it cannot affect the MDI windows list in the popup menu. We tried to reproduce the problem with our MDIDOCVIEW sample application but failed. We would like to ask you to set a breakpoint at the beginning of the CExtPopupMenuWnd::UpdateMdiWindowsMenu() method, run your application and invoke the Window menu in the menu bar when at least one MDI child frame window is open. Please step into the loop inside the CExtPopupMenuWnd::UpdateMdiWindowsMenu() method which has the following for statement:

for( INT nWin = 1; true; nWin++, nCmdID++ )

We wonder how the sWinName local variable is initialized by the following code in this loop?

CString sWinName( _T("") );
CWnd::FromHandle( hWndChildFrame )-> GetWindowText( sWinName );

We guess the window text (caption) of MDI child frames may be empty.

Hello

Thank you for your help. It gets more and more confusing. I noticed that UpdateMdiWindowsMenu was not called at all. So I found out that I had to do several things in order for that method to be called (i.e. SetMdiWindowPopupName). But I noticed that unlike in your MDIDOCVIEW sample there is no second time that the menu is updated (like triggered by _DelayUpdateMenuBar) so I call UpdateMenuBar myself after creation.

Then it hit the method you suggested and the sWinName was empty indeed. So I set the window title after creation of the frame by using SetWindowText.

The strange thing is that I get two menu sections now (see link to screenshot below. Remove "removeme."). Both half filled. If I open the menu a few times and I switch the mdi children then the menu becomes empty again. Somehow the windows become renamed. I spent several hours debugging but I did not find out what is creating my second menu.

Thanks for any help. Thomas.

http://www.ierax.removeme.ch/download/mdiwindow.jpg

We faced the same behavior in the application of one of our customers. It appears only if the menu bar is not enabled for drag-and-drop-based re-docking. Unfortunately we failed to reproduce this bug in any of Prof-UIS samples. That problem has been temporarily solved by handling the CExtPopupMenuWnd::g_nMsgPrepareOneMenuLevel registered message and finding the menu item with the AFX_IDM_FIRST_MDICHILD identifier, removing all the items in the range of AFX_IDM_FIRST_MDICHILD .. (AFX_IDM_FIRST_MDICHILD+9) and inserting a single copy of window list commands.

It would be perfect if you would help us find out what’s wrong with the MDI menu. We would appreciate if you send us a "stripped" but fully functional version of your project which demonstrates the bug.

Hello

Your wish is my command ;-) I stripped almost everything to the bones and the problem still persists. The application is crashing upon closing now which is a result of stripping. The real application doesn’t do that so we can safely ignore this crash. Just open a file (it doesn’t matter which in the stripped version) and the documents will open. If there are questions don’t hesitate to ask.

http://www.ierax.removeme.ch/download/veview.zip (remove the "removeme" part)

Thanks in advance

Thomas

We made several improvements in your project to make the MDI windows list menu working as it must. The following files were modified: MainFrm.cpp, MainFrm.h, VEDocument.cpp, VEDocument.h and ChildFrm.cpp. All the changes are marked as follows:

    // BEGIN: ADDED BY PROF-UIS TECH SUPPORT TEAM
CMainFrame * pMainFrame = CMainFrame::GetMainFrame();
    ASSERT_VALID( pMainFrame );
    // END: ADDED BY PROF-UIS TECH SUPPORT TEAM

or

    // BEGIN: CHANGED BY PROF-UIS TECH SUPPORT TEAM
            pMainFrame->m_hMDIMenu, // NULL,
            pMainFrame->m_hMDIAccel // NULL
    // END: CHANGED BY PROF-UIS TECH SUPPORT TEAM

So, just search for the PROF-UIS TECH SUPPORT TEAM text. There were two problems in your project, which were caused by the following errors:

1) The created instances of the CChildFrm window had no assigned MDI menus.

2) These child frames had no assigned frame window titles.

Please download the improved version of your "stripped" project from our site.

Besides we would like to mention that:

1) Your application is the classic MDI application based on the document/view architecture. So, we have no idea why you did not use the standard MFC document/view features and coded it yourself instead.

2) The application still crashes on shutdown, but we guess this is a result of "stripping".

Thank you very much. The stripped program works fine. I have a problem in the real application though. I have changed everything the way you suggested. When I create the MDI menu the toolbar comes up with a failing assertion on line 455 of exttoolcontrolbar.cpp (see below)

Comments:

• I can create the MDI accel and everything works fine. It’s just the MDI menu that causes trouble.


• The toolbar is fine as long as I don’t open a document. Only when I open a document the assertion comes up


• The assertion seems to happen for the very first button. The index of the loop of buttons seems to be 0

You have asked why I am not using MFC doc/view model. I am using a C DLL that has an intrinsic doc/view model which I would have had to map onto the MFC model. Maybe this would have been possible but I decided against it.

Thomas

ASSERT_VALID( pNode );

return CExtSafeString( pNode->GetTextInToolbar( pCmdItem ) );

}

#endif // (!defined __EXT_MFC_NO_CUSTOMIZE)

ASSERT( pCmdItem != NULL ); <===== pCmdItem is NULL

if( !pCmdItem->m_sToolbarText.IsEmpty() )

sText = pCmdItem->m_sToolbarText;

It seems the information about the child window (document) toolbar or menu bar is not included into the command manager. Have you invoked the following methods?

VERIFY(
  g_CmdManager->UpdateFromMenu(
   pApp->m_pszProfileName,
   IDR_YOUR_DOCUMENT
   )
  );
 VERIFY(
  g_CmdManager->UpdateFromToolBar(
   pApp->m_pszProfileName,
   IDR_YOUR_DOCUMENT
   )
  );

Thank you for your suggestion. There is no child window toolbar or menubar. The assertion seems to happen when the main toolbar is searched for ID_FILE_OPEN which is the very first button on the bar. The following things are noteworthy:

• This only happens when a document is opened. Without open document the buttons on the toolbar are working fine.


• Your stripped program which I downloaded worked fine. The non-stripped version has the same toolbar and more or less the same MDI stuff your version had.


• Your stripped version worked fine even with a document open

Can I provide you with more information? What could be another reason for this to happen?

Thanks in advance

Thomas

If the stripped version of your application works, then the full version must also work. We may review parts of your code (from the full version) but to fix the code remotely (connecting to your desktop) would be much easier and faster. If the latter is appropriate to you, please contact us by e-mail.

Hello

Thank you for your offer to remotely debug the problem. I sent you an e-mail but I think I never got a reply or I overlooked it within my spam.

My suggestion would be to start the session any day this week starting at 10am EST = 4pm CET if this would be convenient for you.

I can even provide a very easy remote desktop program (200kb without install) which goes via an outside server so we won’t have any firewall problems. You can download the client from http://www.deskshare.net/en/support/startclient.aspx. To connect to us you will need a pin code which is valid for two minutes and which I will have to provide. I think if we do this we might also need an instant messenger. I am using Yahoo but I am flexible to install something else.

We are using Windows 2000 that has no built in remote desktop capability.

What do you think? What are your suggestions?

Thanks

Thomas

 

Alex and Sergey

Thank you very much for your support (today and always). We got disconnected but being a Prof-UIS detective I found out that there is another message g_nMsgPrepareMenu that gets sent. So I could finish Sergey’s work and implement the recent file list the way he suggested.

All the best

Thomas

 

The disconnection was caused by technical problems. We are really sorry for that. We are ready to proceed and resolve all the issues left unresolved.

The main things are solved. There are only two questions remaining:

• In the "Windows" menu there remains a useless separator at the bottom of the menu in case there are no open documents. Is there an easy way to remove this or should I use g_nMsgPrepareMenu for this too?


• When I am building the "recently used" file list with ItemInsertCommand: How can I add a text for the status bar (the equivalent to m_sTipStatus in CExtCmdItem)?

Thanks again for your always very good help

Thomas