I am running my English application in Arabic Windows. It contains a property sheet UI (MFC). Everything seems to be fine (Left-To-Right or LTR), except the buttons (OK, Cancel, Apply, and Help) which are Right-To-Left or RTL. But how to make the buttons LTR?
I played around with the flag PSH_RTLREADING mentioned on MSDN but it only deals with the window caption, not the buttons.
Besides, I noticed this dicussion but there is not a good solution.
The answer is given by Raymond Chen [1] and another Microsoft employee [2]; you have to remove the WS_EX_LAYOUTRTL style from the buttons in the window created by your CDialog (aka CPropertySheet). You can either do this globally when you create your CMainFrame and inherit it to all child windows, or locally by changing the window style from GWL_EXSTYLE.
[1] http://blogs.msdn.com/b/oldnewthing/archive/2010/06/11/10023274.aspx
[2] http://social.msdn.microsoft.com/Forums/en/vcgeneral/thread/057612e7-6cd4-44cf-a746-6370ace5de09
Related
I'm trying to use TestStack.White to Automated an MFC Application (for UI testing purposes)
When using TestStack.White with an MFC Application written with CMFCMenuBar (the later Docking framework MFC) I noticed that code like the following fails due to window.MenuBar being null
var menu = window.MenuBar.MenuItem("Window");
menu.Click();
I know I can overcome this issue with the following
TestStack.White.UIItems.MenuItems.Menu windowMenu = win.Get<TestStack.White.UIItems.MenuItems.Menu(SearchCriteria.ByText("Window"));
windowMenu.Click();
But what I really want to do is get the ChildMenus so that I can check the list of windows open in the window menu, but the windowMenu.ChildMenus is empty
I am pretty sure this is because the menu is really a toolbar/toolstrip (dockable)
Does anyone know how to get the menu items (Tile,Cascale,Window1....) from the Window Menu
Has anyone else seen this issue or found a work around?
Thanks in advance
Paul
Yes, the MFC feature pack menu is really a toolbar with buttons. And it is fulfilled using a different process compared to the old style menu.
In your CFrameWndEx derived class, for getting the menu bar you can do:
CMFCMenuBar *pMenuBar= m_Impl.GetMenuBar();
Then it depends on what to do with it. For example, if you want to get the CMenu object that constitutes the menu bar you can do:
CMenu* pMenu= pMenuBar->GetMenu();
If you want to remove some of the menus, you can do (Notice the reverse order):
pMenuBar->RemoveButton(4);
pMenuBar->RemoveButton(3);
You can not get the menu the typical way by YourCFrameWndExDerivedClass::GetMenu() because these new MFC Feature Pack classes intentionally do SetMenu(NULL) when initializing the main frame, as you can see in the call stack:
I am not absolutely sure, but I think you won't also be able to do the override YourCFrameWndExDerivedClass::OnInitMenu() as you could in the old style menus. But you can still use the YourCFrameWndExDerivedClass::OnInitMenuPopup() overrride.
I need to extend an existing MFC app with a UI that will end up very cluttered unless I use a tab control. However, the nature of the UI is that there are some controls that are global, and only some that can be localised to a particular tab.
The standard use of tab controls (CPropertySheet + CPropertyPage) more or less expects there only to be CPropertyPage instances (tabs) visible on the CPropertySheet object, and nothing else. There is a Microsoft Example Project that shows a single additional window painted outside the area occupied by the tab control... but it's not immediately clear how it is created/drawn/handled, and it is only one single additional window that generates few events (I guess it is painted, so there must be a WM_PAINT event handler lurking somewhere).
Is it possible to lay out a bunch of controls with the MS Dialog Editor, including a tab control, and create the CPropertySheet using that template, hook up event handlers in a nice way, etc... or some equivalent way of getting the MFC framework to do as much of the creating, drawing and event handling as possible when it comes to a situation like this?
Yes it is possible to create dialog templates and use them in a CPropertyPage.
Each CPropertyPage behaves nearly like a dialog and handles all events for the controls on it.
Also there are features like OnApply that help you to manage the data exchange between the controls and your internal storage.
The central CPropertySheet only creates the dialog that get active. So OnInintDialog for a page is called the first time when the page gets active.
In the MFC since 2010 are more possibilities than a CPropertySheet. You can create tabbed views, that again may be CFormViews. I don't like CDialog based applications so I would prefer a tabbed view in a standard frame with toolbar and menus if appropriate for the application. So another method to unclutter your UI is to choose the MDI interface with tabbed documents... but multiple documents maybe isn't what you want.
Here is a sample of an SDI application with multiple tabbed views.
Also Coeproject shows some more samples here and with splitters and tabs here.
There are at least three solutions paths:
Try to squeeze the situation into the CPropertySheet + CPropertyPage framework which does not naturally allow for additional dialog controls on the CPropertySheet object, and so you will get no framework support this
Place a tab control on an ordinary dialog, and then use the TCN_SELCHANGE messages to fire code that manually hides & shows individual dialog controls subject to the tab control (again no framework support, but this time "within" the tab control instead of outside it)
Follow Mark Ransom's observation that if you can embed one kind of CWnd-based control on a CPropertySheet then you can probably embed any such object, including a CDialog-based object that has been developed in the MFC Dialog Editor
All of these approaches are going to encounter challenges, and it will depend on the specifics of the situation as to which is better. But first you should really consider whether there is a cleaner UI design which would lend itself to a simpler solution.
In my specific case, I saw no cleaner design alternatives, and found it easiest to take the second approach. It left me with some reasonably simple calls to ShowWindow() to show/hide the controls inside the tab control.
I have a design like below:
So basically, I want to embed three dialogs in the application main dialog and switch between them, for each button click i.e., button 1 will show dialog one , button 2 will hide dialog 1 and show dialog 2 .. and so on.
Each dialog will be having a different design and functions.
I tried using CPropertySheet class to Add pages but its GUI is different. It has either option for navigating the dialogs using next / back button , or from a tab control.
None of which is as per my requirement.
So I want to know is it possible to have a design like this in MFC ? If yes how? Which Class/ control should I use.
Any help will be appreciated.
What you can do is use a normal CDialog class, add your buttons to it and also create a frame/rect as a placeholder for where your embedded dialogs are to appear. The following piece of code will create and position your embedded dialog.
CRect rect;
CWnd *pHost = GetDlgItem(ID_OF_YOUR_FRAME_RECT);
pHost->GetWindowRect(&rect);
ScreenToClient(&rect);
pDialog->Create(ID_OF_YOUR_DIALOG, this);
pDialog->MoveWindow(&rect);
pDialog->ShowWindow(SW_SHOW);
On button clicks, you hide the previously shown dialog (SW_HIDE) and show your selected dialog(SW_SHOW) with ShowWindow(...).
If you create your embedded dialogs with IDD_FORMVIEW style in the add resource editor it'll have the proper styles for embedding.
Another option is probably to use an embedded PropertySheet and hide the tab row and programatically change the tabs on the button clicks. I just find it to be too much fuzz with borders, positioning, validation and such for my liking.
If you have the MFC Feature Pack, that first came with VS2008 SP1 and is in all later versions, you might like to consider CMFCPropertySheet. There are a number of examples on the linked page, that are very similar to your design.
For example, this:
What worked for me just using dialog based application is SetParent() method. Dont know why nobody mentioned it. It seems to work fine.
I am doing like below:
VERIFY(pDlg1.Create(PanelDlg::IDD, this));
VERIFY(pDlg2.Create(PanelDlg2::IDD, this));
VERIFY(pDlg3.Create(PanelDlg2::IDD, this));
::SetParent(pDlg1.GetSafeHwnd(), this->m_hWnd);
::SetParent(pDlg2.GetSafeHwnd(), this->m_hWnd);
::SetParent(pDlg3.GetSafeHwnd(), this->m_hWnd);
Now I can show or hide a child dialog at will (button clicks) as below:
pDlg1.ShowWindow(SW_SHOW);
pDlg2.ShowWindow(SW_HIDE);
pDlg3.ShowWindow(SW_HIDE);
I am writing a C++ application using Qt4 and looking to implement a GUI similar to Firefox 4. That is, I need to remove the default context menu in the top left corner of the window and replace it with three buttons. If you notice the button in Firefox 4 is right at the top in the title bar and I am uncertain as to how this can be implemented.
It won't be easy and will not be cross-platform. Read this thread in the qt forums.
You can obtain the behaviour described by implementing a tool bar. More information can be found at QT documentation on QToolBar
I'm trying to set something up so my main dialog has one or more child dialogs, and these are glued/docked to the outside of the main dialog - when the main dialog is minimised, the children are too, when main dialog moves, children move with it.
I'd tried setting child dialogs as having main dialog CWnd as parent, with CHILD style. But then they get clipped by the parent's boundary. If I set them as POPUP, they can be outside but then don't move with the parent.
I'm looking at putting an OnMove handler on the parent dialog, but is there something built-in? And, should child dialogs still be children of the main dialog... I assume they should?
This is VS2005 (I think VS2008 has some related functionality so I mention this).
You need to implement the movement manually when they are popups, and yes they should be popups otherwise they will be clipped out.
I'm new to SO. Not sure if I can refer to an external article.
I guess this is what you are looking for.
I started to write this class because
I'm often in need to popup additional
dialogs around the main one. Often
these dialogs can give some trouble to
the user; for example, he must
move/close them one by one... A
solution that could give the
application a more solid aspect and
that could make the management of the
various windows easier could be, to
dock all dialogs side by side (like
Winamp does, for example).
As Roel says, your extra dialogs will need to be popups. I'm interested: what kind of UI is this? Is it WinAmp-style, where the windows snap to eachother?
Or are you doing some kind of expanding dialog? If it's an expanding dialog (with a More>> button on it, e.g.), then you can put all of the controls on the same dialog and play with the window rect when showing/hiding the extras.