Professional UI Solutions
Site Map   /  Register
 
 

Forum

Please Log In to post a new message or reply to an existing one. If you are not registered, please register.

NOTE: Some forums may be read-only if you are not currently subscribed to our technical support services.

Forums » Prof-UIS Tech Support » Dialog Menu and Radio Button issues after Prof-UIS version upgrade Collapse All
Subject Author Date
Dave Calkins Jan 22, 2008 - 2:52 PM

I sent this to the support Email address, but thought it would be good to also post it here.
-----------
We just upgraded from v2.60 to v2.82 of the Prof-UIS MFC library and are seeing some issues with one of our apps.

1) Dialog Menu Bar not Rendering

We have a dialog app which has a menu bar. After the upgrade the menu bar no longer shows (the space for it is there, but its not rendering).

Our code is as follows.

- We declare "CCustomPaintManagerHolder<CExtMenuControlBar> wndMenuBar;" in our dialog class (CCustomPaintManagerHolder is a class provided to us by ProfUIS tech support to allow using different look-and-feel themes for different GUI elements; you set a theme for it and it then overrides PmBridge_GetPM() and provides the paint manager you set for that particular item)
- DoDataExchange includes => DDX_Control(pDX,IDC_MY_MENUBAR,wndMenuBar);
- The menu is loaded with the following

if (!wndMenuBar.LoadMenuBar(IDR_MAINMENU))
{
ASSERT(FALSE);
return FALSE;
}
wndMenuBar.m_bCustomizationAllowed = false;
wndMenuBar.SetCustomPM(&pmOffice2003);


2) Radio Buttons not Rendering

The same dialog app also has some radio buttons. We’re using CExtRadioButton. They no longer render, all you see is the background.

Dave Calkins Jan 28, 2008 - 10:51 AM

Just wanted to reply to say that this issue has been resolved. Here’s the info in case someone else runs into the same or a similar problem. I sent a sample project with just the GUI code to tech support and they replied with the below.

===
Your project is absolutely OK and we even have no any comments about how to improve it because everything is correct. The CWnd::RepositionBars( 0, 0xFFFF, 0 ); code in the DMetrisLaserRadar::OnInitDialog() method and it does very important work. It repositions all control bars (menu bar, toolbar) in the dialog and make them placed near borders. As result, control bar windows become resized and menu bar and toolbars re-compute positions of their buttons. The main window is not resizable in your application. So, potentially it’s enough to reposition bars only once at startup. Generally the CWnd::RepositionBars( 0, 0xFFFF, 0 ); code should also be invoked from the dialog’s OnSize() handler method. You can also make toolbar and menu bar to force re-position their buttons by invoking the pBar->SetWindowPos( NULL, 0, 0, 0, 0, SWP_NOMOVE |SWP_NOSIZE | SWP_NOACTIVATE | SWP_NOZORDER | SWP_NOOWNERZORDER | SWP_FRAMECHANGED ); code. It looks like in your real project the menu bar was repositioned before it’s was initialized with buttons or not repositioned at all. The empty menu bar on your screen shot can have such incorrect layout of its buttons if your code repositioned bars first and only then loads menu into menu bar. Please check this issue in your real project. Please also check that the bars were repositioned and this is the absolutely last UI initialization step.
===

In response to the above, I moved the RepositionBars() call to the bottom of the OnInitDialog() method and the problem went away. So it would appear that there was some additional initialization which was ocurring after the RepositionBars() call which, while not causing a problem with v2.60 caused an issue with v2.82. The problem is solved with the move of the call to RepositionBars.

Technical Support Jan 26, 2008 - 12:12 PM

We have read all your e-mails, analyzed your test project and replied you by email.

Dave Calkins Jan 24, 2008 - 2:09 PM

I sent a stripped down project to the support Email address. Note that, after stripping it down, the problem went away. Maybe I’m hitting a resource limitation?

Technical Support Jan 24, 2008 - 12:05 PM

We would prefer to avoid any guesses that may be incorrect. Could you send us a stripped version of your project which contains UI code only and demonstrates the problem?

Technical Support Jan 23, 2008 - 1:18 AM

Actually the problem with radio buttons sounds like magic. There have been no considerable changes with this regard since v. 2.60. And the custom paint manager should not affect the problems you encountered. Could you send us the following parts of your project?

1) Project file.
2) Source code files with UI related code.

We believe we will be able to find what is wrong.

Dave Calkins Jan 23, 2008 - 12:56 PM

The problem with the radio buttons has been resolved. I received an Email from your department which suggested the tab order could be causing the problem. I moved the group box to the bottom of the list in the .rc file (giving it the highest tab-order number) and the problem was gone. The group box was set to non-transparent in the resource editor and was listed before the radio buttons which were inside it resulting in it being rendered after the radio buttons (since the rendering apparently goes from high-tab-order to low) and obscuring them.

The dialog menu is still not rendering though (I checked and its first in the tab-order list). I can’t send you my project. I created a new project and the menu works fine in that. So something is messed up with my project. I also tried renumbering all the resources and rebuilding and still no luck.

One note is that we do make a series of profile calls in our OnInitDialog() (see below). Is it possible that the upgrade from v2.60 to v2.82 is suffering from issues due to profile incompatibility? I deleted everything from the registry under my app key but that didn’t help. Is profile info stored anywhere else?

Here are the profile calls we’re making in OnInitDialog(). Note that the dialog toolbar works fine, its the menu thats no showing up.

----
    VERIFY(
        g_CmdManager->ProfileSetup(
        theApp.m_pszProfileName // __PROF_UIS_PROJECT_CMD_PROFILE_NAME
        )
        );

    VERIFY(
        g_CmdManager->ProfileSetup(
        theApp.m_pszProfileName,
        GetSafeHwnd()
        )
        );

    VERIFY(
        g_CmdManager->UpdateFromMenu(
        theApp.m_pszProfileName, //__PROF_UIS_PROJECT_CMD_PROFILE_NAME,
        IDR_MAINMENU
        )
        );

    VERIFY(
        g_CmdManager->UpdateFromMenu(
        theApp.m_pszProfileName, //__PROF_UIS_PROJECT_CMD_PROFILE_NAME,
        IDR_MYPOPUP_SHOWALL
        )
        );

    VERIFY(
        g_CmdManager->UpdateFromToolBar(
        theApp.m_pszProfileName,
        IDR_MAINTOOLBAR
        )
        );

    VERIFY(
        g_CmdManager->UpdateFromToolBar(
        theApp.m_pszProfileName,
        IDR_MYTYPES
        )
        );
----

Dave Calkins Jan 24, 2008 - 7:53 AM

Here’s another data point on the menu issue. If I run Spy++ and use the find window tool I notice something odd. In older versions of the app running with Prof-UIS v2.60, when I mouse over the app with the Spy++ find window tool all the controls highlight as you move over them.

In the app with the new version, Prof-UIS v2.82, when mousing over the window none of the controls highlight. The only thing which highlights is the dialog window itself, so you’re not able to "find" any of the controls.

I haven’t seen this before but am wondering if this is a clue. Any ideas?

Dave Calkins Jan 24, 2008 - 10:23 AM

I noticed something else. If I hit the Alt key on the keyboard and then use the arrows, the drop down menus appear!! But they appear to be originating from under the title bar and each top menu is at the same location. Any ideas?