QPushButton in QMessageBox missing key shortcut underline on initial display

mrjj · 9 Mar 2016, 12:54

it is.
found setting.

This settings seems to be controlled via
Open Control Panel / Ease of Access Center / Make the Keyboard easier to use.
Underline keyboard shortcuts and access keys.

Harry123 · M mrjj 9 Mar 2016, 12:33

@mrjj

You are right that this setting forces the initial display of the underlines in QMessageBox buttons.
However, for most programs underlines are displayed with or without this setting.

Without this setting, I have tried out several program of mine that display dialogs, and find that some display underlines and some don't.

Weirder and weirder.

mrjj · 9 Mar 2016, 14:12

well My word 2010 did change for fileopen dialog.
Also my notepad++.

But there must be a way to show always in windows API as
some of my programs always show it. Even same buttons.

http://stackoverflow.com/questions/14054036/show-hotkeys-at-all-times
here they use sendmessage to turn it on. Should also be possible in
Qt if no Qt way exists.

Harry123 · M mrjj 9 Mar 2016, 13:05

@mrjj

Yes, my thought exactly.

My code now works and displays the underlines.
It looks like this :

QKeyEvent event(QEvent::KeyPress, Qt::Key_Alt, Qt::NoModifier);
QApplication::sendEvent(msgBox, &event);
msgBox->exec();

However, I would prefer a solution which is less of a kludge, if anyone has a better idea.

Harry123 · 3 Oct 2016, 15:44

This is definitely a Qt design decision to by default paint buttons without shortcut underlines.

I have searched in the sources and found that QWindowsStyle::eventFilter() in qwindowsstyle.cpp does check for Qt::Key_Alt and then repaints all children, all this after calling an internal function named seenAlt().

As it skips all QWidgets having the styleHint of QStyle::SH_UnderlineShortcut, it seems like this is what is missing from my QPushButtons.

How do I add this styleHint to my buttons when creating them ?

mrjj · 9 Mar 2016, 22:52

@Harry123 said:
aha. that is good digging around.
QStyle::SH_UnderlineShortcut seems to belong to the style used by the application.

Im really not sure how to set for a buttons as such. Normally you use a QStyle
in paintEvent for a custom button/widget.

I guess one would have to provide a custom QStyle that somehow altered
this setting.
http://doc.qt.io/qt-5.5/qapplication.html#setStyle

kshegunov · 10 Mar 2016, 11:57

@Harry123
Try the qt_set_sequence_auto_mnemonic function.

Kind regards.

Harry123 · 10 Mar 2016, 12:22

@kshegunov

qt_set_sequence_auto_mnemonic is not found by the linker.
In which library is it supposed to be ?
I have both Qt5Gui and Qt5Core in the link.

kshegunov · 3 Oct 2016, 13:10

@Harry123
My guess would be in the gui module, but I have never used it so I'm not 100% sure. I checked and on my 5.6 build I found it in libQt5Gui.so:

0000000000138d02 T _Z29qt_set_sequence_auto_mnemonicb

So, the answer is: it is located in the gui module.

Harry123 · 10 Mar 2016, 14:44

@kshegunov

Unfortunately it seems to be missing from the Windows build.

kshegunov · 10 Mar 2016, 15:00

@Harry123
Your claim seemed somewhat dubious, so even if I don't actively develop on windows I've loaded the gui module and searched through it with the dependency walker. The symbol is there (Qt 5.5.1 installed with Qt maintenance tool), see the screenshot, and it is exported.

I don't know what error exactly you're getting but you should be able to use the function if declared properly (as mentioned in the documentation I sourced in my previous post).

Harry123 · 10 Mar 2016, 15:07

@kshegunov

Sorry, my claim was more than dubious - unfortunately I put the call in a section of extern "C".
Stupid mistake, but this is a complicated body of code.

Results: calling qt_set_sequence_auto_mnemonic with the parameters of either true or false did not restore the underlines.

kshegunov · 10 Mar 2016, 15:26

@Harry123

Results: calling qt_set_sequence_auto_mnemonic with the parameters of either true or false did not restore the underlines.

That's unfortunate. Another thing you could try is to set a global proxy style for your application and manually force the QStyle::SH_UnderlineShortcut flag.

Kind regards.

Harry123 · 3 Oct 2016, 15:45

@kshegunov

This works. I modified the example in the link with :

    if (hint == QStyle::SH_UnderlineShortcut)
        return 1;

I now have underlines. Much better than faking an Alt key and it works for all future dialogs.

Very many thanks.

kshegunov · 10 Mar 2016, 20:01

@Harry123

faking an Alt key

Well, this could also have unforeseeable side effects as well (if for example some widget has a shortcut bound to that key), so it's a bit hackish.

Very many thanks.

You're most welcome.

Harry123 · 3 Oct 2016, 20:02

@kshegunov

The only question that is left, is why isn't QStyle::SH_UnderlineShortcut the default .

kshegunov · 11 Mar 2016, 09:19

@Harry123
I'd say the default is determined by the OS settings, and Qt simply wouldn't presume to override it. That'd explain why when you change the settings systemwide the behavior changes accordingly.

Harry123 · 3 Nov 2016, 09:27

@kshegunov

I don't think this is a system default, since Qt paints its buttons itself and does not use native widgets.
I say this because if I look into a Qt dialog using Spy++, it has no children, so no native objects.
The reason for this design decision is probably that there was no other way to assure identical functionality across all platforms.

Therefore this is a Qt default which in my opinion is badly chosen, since the Windows default is just the opposite - to always underline button shortcuts in dialogs.

mrjj · wrote on 11 Mar 2016, 09:46

my windows 7 do not have underscore as default.
only when i press alt.
That goes for buttons and menus.
Except some common file open dialog it seems :)

kshegunov · 3 Nov 2016, 10:33

@Harry123

I don't think this is a system default, since Qt paints its buttons itself and does not use native widgets.

Which wouldn't stop it to honor the default system behavior, would it?

As @mrjj noted:

my windows 7 do not have underscore as default.

Which had been my experience as well.

The reason for this design decision is probably that there was no other way to assure identical functionality across all platforms.

This design decision, if memory serves me, happened some time when Qt 4 was developed (which should be about 10 years ago) and it was mostly done because using native handles is costly as hell, and UIs tend to just eat up resources if you have a handle for each tiny thing. And it's been working just fine, if I may add.

Kind regards.