I migrated my MFC MDI application to use the new MFC Feature Pack. I have many toolbars and dockable panes. As far as I understand, the location and size of each of them is saved in the registry when closing the application, and loaded when loading the main frame.
I want to add a feature in my application to reset the layout of the toolbars/panes to the original layout.
I have tabbedpanes also in my application.
sometimes I will dock separate panes to tabbed panes.
Is there a way to actually reset the layout of my application AFTER it has been loaded?
Visual Studio has a similar feature called "Reset Window Layout".
I am getting samples in the internet for restoring mainframe window using SetWindowPlacement() and GetWindowPlacement().
I don't know how to use these functions for toolbars and CDockablePanes and achieve my requirement?
Is there any other solution apart from using SetWindowPlacement() and GetWindowPlacement()?
I am able to meet my requirement using below code.
void CMainFrame::OnPanesResetLayout()
{
CDockingManager* pDockMgr = GetDockingManager();
if (pDockMgr == NULL)return;
CRect rect;
rect.SetRectEmpty();
ClientToScreen(rect);
SetRedraw(FALSE);
CObList list;
pDockMgr->GetPaneList(list, TRUE,0,TRUE);
// UnDock and hide DockingControlBars
POSITION pos;
for (pos = list.GetHeadPosition(); pos != NULL;)
{
CBasePane* pBarNext = (CBasePane*) list.GetNext(pos);
if (!::IsWindow(pBarNext->m_hWnd))continue;
CDockablePane* pBar = DYNAMIC_DOWNCAST(CDockablePane, pBarNext);
if (pBar != NULL)
{
if(pBar->IsAutoHideMode()) pBar->SetAutoHideMode(FALSE, CBRS_ALIGN_ANY);/*ToggleAutoHide();*/
if (pBar->IsMDITabbed ())
continue;
pBar->UndockPane();
ShowPane(pBar, FALSE,FALSE, FALSE);
}
CMFCToolbar* pToolBar = DYNAMIC_DOWNCAST(CMFCToolbar, pBarNext);
if(pToolBar)
pToolBar->m_recentDockInfo.m_recentSliderInfo.m_rectDockedRect = rect;
}
m_wndBar1.DockToFrameWindow(CBRS_LEFT,m_wndBar1.GetAHRestoredRect());
ShowPane(m_wndBar1, TRUE,FALSE, FALSE);
m_wndBar2.DockToFrameWindow(CBRS_RIGHT,m_wndBar2.GetAHRestoredRect());
ShowPane(m_wndBar2, TRUE,FALSE, FALSE);
//for tabbed pane
CTabbedPane *pTabbedPane;
m_wndTab1.DockToFrameWindow(CBRS_BOTTOM,m_wndTab1.GetAHRestoredRect());
m_wndTab2.AttachToTabWnd(&m_wndTab1, DM_SHOW, FALSE,reinterpret_cast<CDockablePane**>(&pTabbedPane));
m_wndTab3.AttachToTabWnd(&m_wndTab1, DM_SHOW, FALSE,reinterpret_cast<CDockablePane**>(&pTabbedPane));
ShowPane(m_wndTab1, TRUE,FALSE, FALSE);
ShowPane(m_wndTab2, TRUE,FALSE, FALSE);
ShowPane(m_wndTab3, TRUE,FALSE, FALSE);
SetRedraw(TRUE);
RedrawWindow(NULL, NULL, RDW_INVALIDATE | RDW_UPDATENOW | RDW_ERASE | RDW_ALLCHILDREN);
AdjustClientArea();
}
As described in my comment above, one option to restore the initial layout from a running application would be to use the methods provided by CDockablePane, specifically
AttachToTabWindow
DockToWindow and
ShowPane
A second option, which would require restarting your application, is to call EnableLoadDockState(FALSE) in the constructor of your CFrameWndEx derived class. This would prevent loading the stored dock state and, as a consequence, restore the initial layout.
A simple method to solve this is to delete from registry key all keys which store the panels info: "BasePane" and "Pane" from "Workspace" registry folder from your app registry entry :) Easy.
Related
I created an SDI app with a single menu and a single toolbar in MFC:
I am supposed to show/hide the toolbar dynamically via this code:
...
m_wndToolBar.ShowWindow(SW_HIDE);
...
It did visually hide the toolbar but left a blank, seemingly still working space in the dock region that blocks the main view repositioning. And, when I try to drag the menu, it can dock to the top and bottom line just like the toolbar is there.
I must have missed some necessary steps. So how can I "really" remove the toolbar and raise the main view close to the menu?
Assuming you are using a (relatively) recent version of MFC, and that your m_wndToolBar member is a CMFCToolBar (or derived therefrom), then you should use the ShowPane() member function, rather than the more general ShowWindow() member. Using the former allows the Framework to make the required adjustments to the docking system.
From the linked document:
Call this method instead of the CWnd::ShowWindow when showing or
hiding dockable panes.
(Note that a CMFCToolBar is derived from CPane via the CMFCBaseToolBar class.)
In your call to ShowPane(), the first argument will be TRUE to show the toolbar or FALSE to hide it; the other two arguments will most likely be FALSE, as you want to readjust the docking layout immediately and you generally don't want to activate a toolbar.
So:
//...
m_wndToolBar.ShowPane(FALSE, FALSE, FALSE); // Hide toolbar
//...
Or:
//...
m_wndToolBar.ShowPane(TRUE, FALSE, FALSE); // Show toolbar
//...
Note also that ShowPane() (or, rather, a version of it) is called by the Framework's default handler for a show/hide menu item with the ID of any toolbar (which toggles its visibility); from "afxframewndex.cpp":
BOOL CFrameWndEx::OnPaneCheck(UINT nID)
{
ASSERT_VALID(this);
CBasePane* pBar = GetPane(nID);
if (pBar != NULL)
{
ShowPane(pBar, (pBar->GetStyle() & WS_VISIBLE) == 0, FALSE, FALSE);
return TRUE;
}
return FALSE;
}
I'm trying to place a window either above or below the icons on the desktop. I mostly just want it to stay attached to the desktop at all times. Similar to Rainmeter or Wallpaper engine. So far, everything I tried either disables interaction, or gets minimized when you use the "Show Desktop" button. Any ideas on how to achieve this? I'm using electron and a native module in node to do this.
It's an old subject, but I'll find out how to do it recently and answer it.
The method is to find the handle of SHELLDLL_DefView, the parent of the desktop window, and then make the SHELLDLL_DefView handle the parent of my window to fix it to the desktop.
The method is to find the handle of SHELLDLL_DefView, the owner of the desktop window, and then make the SHELLDLL_DefView handle the owner of my window to fix it to the desktop.
SHELLDLL_DefView is located under the Progma or WorkerW handle. This is a code to prevent ShowDesktop from being used in the Electget package created by ffi-napi to attach the Electron browserWindow to the desktop.
const GWLP_HWNDPARENT = -8;
// find SHELLDLL_DefView in Progma
const progman = user32.FindWindowExA(ref.NULL, ref.NULL, 'Progman', ref.NULL);
let defView = user32.FindWindowExA(progman, ref.NULL, 'SHELLDLL_DefView', ref.NULL );
// find SHELLDLL_DefView in WorkerW
if (!defView) {
const desktopHWnd = user32.GetDesktopWindow();
let workerW = 0;
do {
workerW = user32.FindWindowExA(desktopHWnd, workerW, 'WorkerW', ref.NULL);
defView = user32.FindWindowExA(workerW, ref.NULL, 'SHELLDLL_DefView', ref.NULL );
} while (!defView && workerW);
}
if (!defView) return false;
// make the SHELLDLL_DefView handle the parent of my window
user32.SetWindowLongPtrA(hWnd, GWLP_HWNDPARENT, defView);
This allows you to create a window where you can click and interact without being hidden by ShowDesktop.
2022-03-29
There was a wrong word, so I corrected it. According to doc, it is not a parent window, but an owner window. In the doc, it is strange that the GWLP_HWNDPARENT constant is related to the parent window. However, when tested with Spy++, the corresponding constant changes the owner window.
I'm coding a custom Win32 UI control that I want to incorporate visual themes in. I load themes in its WM_NCCREATE as such:
case WM_NCCREATE:
{
HTHEME hTheme = ::OpenThemeData(hWnd, L"EDIT");
assert(hTheme);
assert(::GetWindowTheme(hWnd) != 0);
}
return 1;
and then release them when control is destroyed:
case WM_DESTROY:
{
HTHEME hTheme = ::GetWindowTheme(hWnd);
assert(hTheme);
if(::CloseThemeData(hTheme) != S_OK)
{
assert(NULL);
}
}
break;
This works well, until someone tries to change that control's styles. The following call (just by itself without even changing any styles):
::SetWindowLongPtr(hChildWnd, GWL_STYLE, dwStyle);
will make GetWindowTheme on hChildWnd return NULL.
So, is it a bug or a feature?
PS. To make a reproducible Win32 example I had to adjust the stock Win32 solution from the VS 2017. (Here is its full source code.) The way it works is this: in it I create a small child control (shown in gray below) that has theme in question:
Then when you click on the white area of the main window, I try to change its styles and its theme disappears:
To see the full Win32 code for that project, I also posted it on PasteBin.
According to Window Styles document:
"After the window has been created, these styles cannot be modified,
except as noted."
Because this is not permitted, the theme engine does not always check for changed styles and in some circumstances will draw the caption based on old data. And the only guaranteed and supportable solution is for the application to destroy the window and recreate it with the new styles rather than trying to change them on the fly.
A similar discussion can be found:
http://social.msdn.microsoft.com/Forums/en/windowscompatibility/thread/7b5ef777-ff0d-4f15-afed-5588f93f0e23
I'm not sure why am I getting this visual artifact?
Here's how to repro:
I'm using Visual Studio 2017 Community. Create a new C++ -> MFC project:
Then specify "dialog based":
Then build as "Debug" x86 app and run it.
So I'm running it on Windows 10.
When this dialog-based process has focus, it looks as I would expect it:
but if I switch keyboard focus to some other app (by clicking on it), this dialog-based process still retains its title bar color:
I'm not sure if it's just a matter of a visual glitch or if there's a deeper mess-up with the window message handling. How do I correct it? (This wasn't an issue with older MFC projects.)
I managed to replicate your problem and found a quick fix for it.
You need to add the WM_ACTIVATE message handler to your main dialog, comment out the base class OnActivate and modify it like this:
void CMFCApplication1Dlg::OnActivate(UINT nState, CWnd* pWndOther, BOOL bMinimized)
{
//CDialogEx::OnActivate(nState, pWndOther, bMinimized);
// TODO: Add your message handler code here
this->Default();
}
CWnd::Default call is needed to keep the active/inactive visualization of the default button.
OK, as much as I appreciate #VuVirt's solution, it doesn't completely remove all the bugs that are shipped in the default Dialog-based solution in VS2017. It solves the title bar focus issue, but while continuing to develop my project I encountered another bug. So I'm copy-and-pasting it from my comment to his answer:
There's still some kinda screw-up there. I'm not sure if it's related to this fix or not. Ex: If you create a button and then in its handler try to do: CFileDialog d(TRUE, NULL, NULL, OFN_HIDEREADONLY | OFN_EXPLORER, NULL, this); d.DoModal(); to open a file picker dialog. When file picker opens up, close it and see if the title bar of the parent MFC dialog window goes back to being active. In my case it remains inactive until I click onto the Windows taskbar and then back onto that MFC app.
After banging my head against the wall trying to see what is going on there, I decided to try an earlier solution proposed by #zett42 in the comments to my original question (i.e. to replace CDialogEx with CDialog) and it worked! All the bugs are gone!
So here's my verdict: CDialogEx is buggy af.
The resolution is quite simple: When you create a new dialog-based project use project-wide find-and-replace (in the Edit menu) and replace all occurrences of CDialogEx with CDialog. And that is it. (I tried to use VS2017's refactoring tool for that but it messed it up and didn't replace it all. So simple search-and-replace does the job.)
And if you think that you'll be missing some functionality without CDialogEx, then you won't. All it does (besides introducing bugs) is that it adds background images and colors to the dialog.
So until MS fixes those glaring bugs in their templates I'm sticking with this approach.
This seems to be a bug in CDialogImpl::OnActivate and CDialogImpl::OnNcActivate:
void CDialogImpl::OnNcActivate(BOOL& bActive)
{
if (m_Dlg.m_nFlags & WF_STAYACTIVE)
bActive = TRUE;
if (!m_Dlg.IsWindowEnabled())
bActive = FALSE;
}
void CDialogImpl::OnActivate(UINT nState, CWnd* pWndOther)
{
m_Dlg.m_nFlags &= ~WF_STAYACTIVE;
CWnd* pWndActive = (nState == WA_INACTIVE) ? pWndOther : &m_Dlg;
if (pWndActive != NULL)
{
BOOL bStayActive = (pWndActive->GetSafeHwnd() == m_Dlg.GetSafeHwnd()
|| pWndActive->SendMessage(WM_FLOATSTATUS, FS_SYNCACTIVE));
if (bStayActive)
m_Dlg.m_nFlags |= WF_STAYACTIVE;
}
else
{
m_Dlg.SendMessage(WM_NCPAINT, 1);
}
}
This is meant to give CDialogEx the ability to stay active, for example, when CMFCPopupMenu is shown.
But m_Dlg.SendMessage(WM_NCPAINT, 1) is a suspicious call. The usage doesn't match the documentation for WM_NCPAINT:
Parameters
wParam
A handle to the update region of the window. The update region is clipped to the window frame.
lParam
This parameter is not used.
Additionally, OnNcActivate has an override based on IsWindowEnabled(). This seems to be a patch to fix the earlier problem in OnActivate. But it causes problems elsewhere, for example when using CFileDialog in CDialogEx
Suggested solution:
Modify CDialogEx::OnActivate so that it runs the default procedure. Or, change it such that it will force repaint.
BOOL CDialogEx::OnNcActivate(BOOL active)
{
if(m_nFlags & WF_STAYACTIVE)
active = TRUE;
return(BOOL)DefWindowProc(WM_NCACTIVATE, active, 0L);
}
void CDialogEx::OnActivate(UINT nState, CWnd* pWndOther, BOOL bMinimized)
{
Default();
}
or
void CDialogEx::OnActivate(UINT nState, CWnd* pWndOther, BOOL bMinimized)
{
Default();
//save the previous flag
UINT previous_flag = m_nFlags;
m_nFlags &= ~WF_STAYACTIVE;
// Determine if this window should be active or not:
CWnd* pWndActive = (nState == WA_INACTIVE) ? pWndOther : this;
if(pWndActive != NULL)
{
BOOL bStayActive = pWndActive->GetSafeHwnd() == GetSafeHwnd() ||
pWndActive->SendMessage(WM_FLOATSTATUS, FS_SYNCACTIVE);
if(bStayActive)
m_nFlags |= WF_STAYACTIVE;
}
if(previous_flag != m_nFlags && previous_flag & WF_STAYACTIVE)
{
//if the flag is changed,
//and if WF_STAYACTIVE was previously set,
//then OnNcActivate had handled it wrongly, do it again
SendMessage(WM_NCACTIVATE, FALSE); //<- less wrong!
}
}
This should work with CMFCPopupMenu for example. The MFC menu will open without deactivating the dialog.
I am not sure what SendMessage(WM_FLOATSTATUS, FS_SYNCACTIVE) is for, I haven't been able to test it... If it's necessary, it seems the code could be added on OnNcActivate, and then OnActivate is left alone.
I'd like to switch between different ribbons for different MDI child frames in my application. I know it's possible with the old style menus, but I can't get it working with the feature pack ribbons.
The code used when it's old style menus:
pDocTemplate = new CMultiDocTemplate(
IDR_MAINFRAME,//Menu to load
RUNTIME_CLASS(CModDoc),
RUNTIME_CLASS(CModFrame), // custom MDI child frame
RUNTIME_CLASS(CdotView));
if (!pDocTemplate)
return FALSE;
AddDocTemplate(pDocTemplate);
pDocTemplate = new CMultiDocTemplate(
IDR_RES_RNGACTIV,//Menu to load
RUNTIME_CLASS(CModRangeDoc),
RUNTIME_CLASS(CModRangeFrame), //custom MDI child frame
RUNTIME_CLASS(CBlankView));
if (!pDocTemplate)
return FALSE;
AddDocTemplate(pDocTemplate);
Another approach I'm thinking of is to unload the current Ribbon and load a new Ribbon from resources?
//Unload ribbon code?
m_wndRibbonBar.LoadFromResource(IDR_RIBBON);
there is no need to have multiple CMFCRibbonBar objects if you don't need to, you can just use the CMFCRibbonBar::LoadFromResource and then you will have to use the CMFCRibbonBar::RecalcLayout method to apply the changes to the User Interface.
Remember to check the return value of CMFCRibbonBar::LoadFromResource to be sure that the load was successful, and it is really important that you call the CMFCRibbonBar::RecalcLayout otherwise you will not see the new ribbon.
I ended up hiding the original ribbonbar and then loading and displaying a new one. Not sure if it's the best way to do it though.
CMultiDocTemplate *pDoc = GetDocTemplate(7);
if (pDoc)
{
CFloorActivDoc* pDocument = (CFloorActivDoc*)pDoc->CreateNewDocument();
CFloorFrame* pFrame = (CFloorFrame*)pDoc->CreateNewFrame(pDocument, NULL);
if (pFrame)
{
pDoc->InitialUpdateFrame(pFrame, pDocument);
m_wndRibbonBar.ShowPane(FALSE, FALSE, TRUE);//Hide original ribbon
m_FloorRibbonBar.Create(this);
m_FloorRibbonBar.LoadFromResource(IDR_RIBBON_FLOORACT);
}