I have a QMainWindow with three QPushButtons (arranged in a QVBoxLayout in a QWidget). All have the same properties, except objectName, icon and iconSize. All are enabled and have two icons, one for normal and one for disabled.
When I start my application, always the top most icon shows the disabled icon (but is working, so it is enabled) the other two are fine. As soon as a focusable control in that window gets the focus, the icon changes to the active one and everything is fine.
Calling update or repaint in the showEvent of the window doesn't help either.
I'm using gcc 4.8.1 and qt 5.1.0.
Any ideas how to handle this glitch?
Update: It gets more strange: Starting the program, the icon shows disabled, getting another application the focus, the icon shows enabled, bringing the window on top again without giving it the focus (e.g. by using the task bar) changes the icon back to diabled. Clicking a control in the window, which can have focus will fix it again.
Well, well I finally got it. I just set the focus manually in the code and realized, that the icons were set in a wrong way. If a button was currently focussed it displayed the disabled icon. I had messed up the different button states and too many states got the disabled icon.
Related
I have a menu with checkable QActions in it: (ed: these calls are within a QWidget subclass, so 'this' points to the associated widget).
QAction* action = new QAction(icon, actionName, this);
action->setCheckable(true);
action->setActionGroup(m_actionGroup);
menu->addAction(action);
This menu is attached to a tool button, which is in a QWidget with a few other tool buttons. Previously, it was part of a larger widget, but I've been refactoring to confine some things together.
When it was previously part of the larger widget, these actions and their icons displayed fine. Now, however, the icons are drawn in a dotted pattern and a box for a check box is drawn on top. When I hover over an action, the dotted action goes away entirely, and it's just the check box. When I select an action, the icon appears normally.
I've tried doing the same in a little toy program, and the menu displays correctly then, so I'm having trouble reproducing the issue outside of my rather large program. Has anyone seen behaviour like this before, or know how to fix it?
Qt 5.5 on Ubuntu 16.04 is the platform information.
Edit: It gets even stranger. The original implementation created the QMenus without parents. Which I would have avoided because of memory leak concerns. But if you create the menu with the widget holding the button as a parent, then you get this behaviour. It's something about the QMenu being constructed with a parent that is creating issues, not the QAction.
In an C++ MFC project I'm using CMFCMenuButton using MSVC 2013.
When I toggle the high contrast mode the button is not properly repainted (for comparison a normal button is displayed):
Calling Invalidate() or ShowWindow(SW_HIDE);ShowWindow(SW_SHOW); seem to have no effect - even minimizing the dialog does not cause a proper redraw. How can I force the button to repaint with the updated system color?
Update: Forcing the colors after toggling contrast mode just makes the button text visible, however the button itself, the border, is not visible.
m_ctrlOkButton.SetFaceColor(::GetSysColor(COLOR_BTNFACE));
m_ctrlOkButton.SetTextColor(::GetSysColor(COLOR_BTNTEXT));
Took me a while, but I was able to solve this. I'm inheriting from the CMFCMenuButton class so that I can handle some events:
Get the color on the button right:Handle the WM_SYSCOLORCHANGE event and call GetGlobalData()->UpdateSysColors(); (make sure it's propagated to our parent before, e.g., by __super::OnSysColorChange();)
Get the border and background right:Handle the WM_THEMECHANGED event and call CMFCVisualManager::GetInstance()->DestroyInstance(); in order to close all opened theme data handles.
There is a feature in Windows: If current window is not activated, main menu of this window looks disabled (but in fact it is just grayed out, so you can click on any item in this menu). It is ok when you switch to another program, but it looks wrong when you go to child window.
It is easy to reproduce this effect even with standard Notepad:
Put any text in it,
Press Ctrl+F,
Now you can see that main menu looks disabled, but you can click on any item in it.
The question is following: How to block this effect for my program only? In my program (C++ and Qt) I have the same graying out of all items in the main menu when user goes to child windows. Is there a way to stop it?
I do not put any code here, because this effect it reproducible in the most of programs. But I hope that it is possible to change flags/properties of my QMenu or QMenuBar to correct this behavior. Is it possible?
We can correct a palette of the QMenuBar to substitute a text color in inactive state with text color in active state.
The code:
QPalette pal = pMenuBar->palette();
QColor col = pal.color(QPalette::Active, QPalette::ButtonText);
pal.setColor(QPalette::Inactive, QPalette::ButtonText, col);
pMenuBar->setPalette(pal);
After it user will not see graying out of items in a main menu, because text colors of active and inactive items will be the same.
(Theoretically it is possible that background color of active and inactive states of the same item are different. So it might be reasanoble to make the same replacement for background too)
Recently, I've got stuck over strange UI issue, found a solution, but still unsure about problem cause.
Preconditions:
MFC MDI application has 2 modeless dialogs opened, both has a child third-party grid and CToolTipCtrl. Dialog windows crosses each other borders (i.e. active dialog is overlapping part of inactive one). CToolTipCtrl is similar to example, the only tool set for tooltip is grid. Parent of tooltip is There is the corresponding dialog's grid, TTS_ALWAYSTIP style is set to allow tooltips on inactive dialog.
Issue:
When mouse is hovering on inactive dialog's grid, tooltip is appearing and inactive dialog is drawn over active one. In other words, inactive window is brought to top without activating. It's drawn completely, including caption, buttons, grid, etc.
I've checked Z-order and found that inactive dialog is still inactive, even when shown on top. No Z-order changed. Then I gathered message log using Spy++ for whole inactive dialog while tooltip is appearing and found no WM_ACTIVATE, WM_FOCUS, WM_MDIACTIVATE, etc. Then I performed search about how to bring window up without activating and logged SetWindowPos calls - the only calls are performed for CToolTipCtrl's window. So, no SetWindowPos for dialogs called. No BringToTop() called as well.
Solution
I've changed tooltip's parent window from dialog's grid to dialog itself - and that fixed problem. However, I still have no idea what was happened and why changing parent attribute matters.
Question
Could anyone give me a hint about what I'm missing? Maybe, tooltip causes repaint of grid, and that repaint has a bug causing repaint over active window, but I haven't found any proofs yet.
Haven't found something specific about tooltip's parent property in MSDN as well. Maybe, I have to read somenting about Windows GDI?
I am making an SDI MDF application that uses a frameview to provid the user with a set of controls (buttons, editboxes and such). The view also owns a set of CDialogs used to desplay aditional controls that can be can be shown or hidden via a tabcontrol and other means. Untill recently the dialogs have been staticly placed at creation to be in their proper location on the screen but I wanted to add a dialog that the user could move around but is still a child of the view. When I created a dialog with a caption and sysmenu that the user can move around the issue I am running into is that when the window is placed over another control owned by the view, (lets say a button) when the paint method is called on the button, it draws over the dialog. The dialog is still on top and the dialogs controls can still be interacted with but the button is drawn over them untill the dialog is repainted. I have tryed to change the clipchild and clipsiblings settings of the dialog and have been able to get the dialogs to properly clip eachother but can not seem to get the child dialog to properly clip the parent view controls. Does anyone have any ideas on what setting might fix this clipping issue.