I'm working on upgrading an older MFC/C++ application to use the MFC Feature Pack upgrades.
I've swapped out the old toolbar/menu for a ribbon, and found that if using the autohide feature of the CDockablePanes, the resulting CMFCAutoHideBar stretches the entire span of the app window and is overlapped by the top-most bar of the ribbon.
How can I avoid this?
Related
Precondition: The application is MFC C++ that uses BCGControlBar library for UI rendering.
Topic:
We can add Backstage Views and Commands to BCG Ribbon Backstage Main Panel.
Something like it:
auto pBackstagePanel = m_wndRibbonBar.AddBackstageCategory(_T("File"), IDB_FILESMALL);
// views
pBackstagePanel->AddView(ID_BACKSTAGE_INFO, _T("Info"), new CBCGPRibbonBackstageViewItemForm (IDD_FORM_INFO, RUNTIME_CLASS(CBackStagePageInfo)));
pBackstagePanel->AddView(ID_BACKSTAGE_RECENT, _T("Recent"), new CBCGPRibbonBackstageViewItemForm (IDD_FORM_RECENTFILES, RUNTIME_CLASS(CBackStagePageRecentFiles)));
// commands
pBackstagePanel->AddCommand (ID_FILE_SAVE, _T("Save"), 2);
pBackstagePanel->AddCommand (ID_OPTIONS, _T("Options"), 3);
pBackstagePanel->AddCommand (ID_APP_EXIT, _T("Exit"), 3);
But BCG Backstage Main Panel has UI bug: ribbon buttons for views (method AddView()) and commands (method AddCommand()) are rendered with different widths!
So hovered or focused state of ribbon button for command are rendered narrower than for views by around 6px.
You can see this bug even in BCG samples that use BCG Ribbon (e.g DrawCli):
Question:
Do you know the way how to fix it and have equal width for all elements in the backstage main panel?
BCGSoft will not fix anything. I have used their lib for years and their 48 hours "help" is useless. Basically, they always reply that the reported problem is MFC and not with their software. It is so poor, I am re-writing my entire framework into straight MFC. This removes the GUI lib's layer of indirection. Not that MS is much better at responding to GUI MFC bugs, though.
My app is Win32; I'm using VS 2015. I have a dialog box that contains a listbox. I set the listbox to be dynamically resized, but it does not change when the dialog is resized.
Here are the listbox' attributes:
The listbox is owner-drawn:
This is the default size of the dialog:
This is what the dialog looks like when I stretch in Test mode in the Resource Workshop Dialog Editor. Notice the inside listbox expands too, exactly as hoped:
However, when it's actually running, stretching the dialog does not increase the size of the listbox:
Why is this not working? Is there some additional voodoo I have to invoke to get it to actually work? Does this only work in MFC? What is the Win32 equivalent of CWnd::ExecuteDlgInit?
Note: I have already looked at https://msdn.microsoft.com/en-us/library/mt270148.aspx and http://mariusbancila.ro/blog/2015/07/27/dynamic-dialog-layout-for-mfc-in-visual-c-2015/, wherein I did not find an answer.
Does this only work in MFC?
Indeed, this only works when using MFC1.
What is the Win32 equivalent of CWnd::ExecuteDlgInit?
MFC is a library built on top of the Windows API. The windowing system in the Windows API does not provide any sort of layout management. If you want to see the Windows API equivalent, it's literally what is implemented in MFC.
So, why is this supported in the graphical resource editor then? Because that is where the layout information is generated. It's ultimately placed into a custom resource of type AFX_DIALOG_LAYOUT, where MFC picks it up to do its magic. If you aren't using MFC, that resource is simply ignored.
That's not to say that - in theory - you wouldn't be able to implement your own solution that reads the generated resource. As long as you can find documentation for the custom resource used by MFC. I didn't, but a look into the MFC source revealed, that it's pretty simple (a version WORD, followed by pairs of WORDs for horizontal and vertical move and size settings).
1 Or a library that understands the implementation details, such as the WTL.
This functionality is also supported in Windows Template Library!
https://sourceforge.net/p/wtl/git/ci/master/tree/Include/atlframe.h
If you have a look at the CDynamicDialogLayout class you can see how it works, and if you are using WTL you can even use the functionality yourself.
For the record, I was looking for the solution to this as well, when I resized a control on my dialog all of the dynamic resizing stopped working, although it worked fine in the Test Mode.
To fix it, in the the second link you posted there's a section on adding a function:
void CMFCDynLayoutDemoDlg::SetupDynamicLayout()
Where you re-setup the Dynamic Layout manager
Once I did this, it started working in the live version for me.
Very similar answer is in this post too:
Recalculate dynamic layout properties
I recently migrated my source code to Gtkmm 3.20. In this versión of gtk appears an automatic popover.
How I can remove this functionality? See image.
This is a new feature of GTK+ 3.20: if the GtkEntry sees touch events, which happens if you use a touchscreen and tap the entry, then it will automatically show that popover, which contains touch-friendly editing buttons (Paste is what you see there; I presume Cut, Copy, and Select All would be available on a non-password GtkEntry as well).
There is no way to turn that off, however it should only show up when you touch the GtkEntry; if you use keyboard or mouse navigation, it shouldn't show up. If it still does, you can report that as a bug to the GNOME Bugzilla.
It seems you are implementing a PIN entry field. I agree that in that case the popover isn't needed. You should state that case directly to the GTK+ developers then; maybe they will provide an API to turn the popover off (but it will not be part of GTK+ 3.20).
I have a large C++ application with a mostly homegrown layer for GUI Abstraction etc. The application is plain C/C++ on Win32 API.
So far the application only supports a static horizontal toolbar which can not be modified in any way at runtime (besides enabling/hoovering visualization).
We thought about switching to a ribbon interface but nobody we asked liked that idea.
So we want to add some sort of toolbar with the following capabilities:
Movable and resizeable (acting as floating windows/palettes)
Use Bitmaps of any Size
Supports User configured Toolbars Supports
Enabling/Disabling/Checked State
Preferably create disabled/checked/hoovering state bitmaps automatically
How can this be done with the least effort?
I looked at rebars and the TOOLBAR API. Rebars seem not to be resizeable and i was unable to find a working sample for toolbars.
Working sample: here's what I could find: tutorial with link to full example code, part-3 covers toolbars
I've forced with a possible bug feature of MFC Feature Pack under Windows Vista. It can be easily recreated:
Create a new SDI app using MFC Feature Pack (with Ribbon based interface). You can also add some floating panels if you want;
Do not change anything, just build a Release;
Close the Visual Studio, run the application and turn your computer into Sleep Mode (Hibernation).
Restore the computer from the sleep mode and you will see that the application did not restore well: it does not correctly display window's caption; it is impossible to increase the window size (it cuts the frame), etc.
Did anyone forced with this behavior?
I'm using Windows Vista Business SP2 and getting the same behavior on my desktop and laptop. Unfortunately did not tested under XP or another platform.
PS: I've solved the mentioned problem for toolbar based application by switching the visual style to any other and back on receiving WM_POWERBROADCAST. But the trick does not work for ribbon based application.
I had the same problem, thanks for the tip, and looking for it I found a solution, I only tried it in an app with toolbar, I have not tried it in Ribbon, if it works in ribbon confirm me please.
What works for me:
// add to class CMainFrame :
UINT CMainFrame::OnPowerBroadcast(UINT nPowerEvent, UINT nEventData)
{
// Comment "default return" and return true
//return CMDIFrameWndEx::OnPowerBroadcast(nPowerEvent, nEventData);
return true;
}
Source: msdn forum.