Focus bug in windows

[zerobala]

Hello,

I'm desperate with tab order.

Qt Designer's tab order editing won't function for custom widgets (they show up as a single widget). I got nowhere using QWidget::setTabOrder. So I decided to re-implement focusNextPrevChild (build a QList of widget*, run through the list and do setFocus()) in a class and call it from my windows.

It works fine on Linux. The problem is: windows XP just won't paint the focus, but it's there (e.g. if I hit spacebar the button will click). Tried a lot of work-arounds and I'm very frustrated.
The funny thing is, I created an empty form with some buttons and tried setFocus() with no success. But after I hit tab and Qt changes and paint focus, setFocus() will paint correctly.

What's the method Qt uses for giving focus to a widget?

[jpn]

Hi. Check the focusPolicy of your custom widget.

[zerobala]

Hi. Check the focusPolicy of your custom widget.

Already did.
Even set focusPolicy on each of the 3 buttons of my custom widget on the constructor, it still won't work.

[jpn]

Qt Designer's tab order editing won't function for custom widgets (they show up as a single widget).

Are we talking about promoted custom widgets or did you write a designer plugin for the custom widget?

The funny thing is, I created an empty form with some buttons and tried setFocus() with no success. But after I hit tab and Qt changes and paint focus, setFocus() will paint correctly.

Does the problem exists in Designer only?

[zerobala]

Are we talking about promoted custom widgets or did you write a designer plugin for the custom widget?


Does the problem exists in Designer only?

I wrote a designer plugin.

No, the problem shows when I try to use setFocus() in my application (only in windows). But it's not exclusive to custom widgets.
The fact is, an empty form with two buttons, the click slot of the first connected to setFocus() on the second and this won't paint the focus in Windows XP. But if I tab through the widgets and just one button-like focus (the "focus frame" like in the checkbox) is painted, then setFocus() will work correctly.

Sorry if my english is bad, I'm brazilian

[jpn]

The fact is, an empty form with two buttons, the click slot of the first connected to setFocus() on the second and this won't paint the focus in Windows XP. But if I tab through the widgets and just one button-like focus (the "focus frame" like in the checkbox) is painted, then setFocus() will work correctly.

Could you attach such example, please? I'd like to take a look.

[zerobala]

Could you attach such example, please? I'd like to take a look.

Button "apply" should paint focus on "cancel" and vice-versa, but they'll work properly only after focus is painted on one of the buttons via tab.

[jpn]

Looks like windows style implementation actually has a check that the button focus is only drawn when focus has been changed with the keyboard (tab, backtab, or shortcut), in other words, when attribute Qt::WA_KeyboardFocusChange is set. This can't even be worked around by passing appropriate focus reason (which I suspected to solve the problem at first sight)

btCancel->setFocus(Qt::TabFocusReason);

btCancel->setFocus(Qt::TabFocusReason);

To copy to clipboard, switch view to plain text mode 

One would have to set the attribute to the top level window by hand. I'm afraid I cannot recommend such workaround because it could break something else. Here it goes anyways

window()->setAttribute(Qt::WA_KeyboardFocusChange);
btCancel->setFocus();

window()->setAttribute(Qt::WA_KeyboardFocusChange);
btCancel->setFocus();

To copy to clipboard, switch view to plain text mode 

You can always send a bug report to Trolltech if you feel it should behave differently.

Edit: Oh, and there is another way to work it around I forgot to mention. A custom style which returns true for QStyle::styleHint(QStyle::SH_UnderlineShortcut).

[zerobala]

Looks like windows style implementation actually has a check that the button focus is only drawn when focus has been changed with the keyboard (tab, backtab, or shortcut), in other words, when attribute Qt::WA_KeyboardFocusChange is set. This can't even be worked around by passing appropriate focus reason (which I suspected to solve the problem at first sight)

btCancel->setFocus(Qt::TabFocusReason);

btCancel->setFocus(Qt::TabFocusReason);

To copy to clipboard, switch view to plain text mode 

One would have to set the attribute to the top level window by hand. I'm afraid I cannot recommend such workaround because it could break something else. Here it goes anyways

window()->setAttribute(Qt::WA_KeyboardFocusChange);
btCancel->setFocus();

window()->setAttribute(Qt::WA_KeyboardFocusChange);
btCancel->setFocus();

To copy to clipboard, switch view to plain text mode 

You can always send a bug report to Trolltech if you feel it should behave differently.

Edit: Oh, and there is another way to work it around I forgot to mention. A custom style which returns true for QStyle::styleHint(QStyle::SH_UnderlineShortcut).

Thank you for your help!

[zerobala]

Oops, it's not working for toolbuttons on default XP theme, same problem. Any suggestion?

[jpn]

Oops, it's not working for toolbuttons on default XP theme, same problem. Any suggestion?

I guess this is specific to WinXP. It seems that QToolButton does not draw any focus rect at all on WinXP. Try your app with old windows-style ("myapp.exe -style windows") and it will.

PS. Sorry for late response. I was in hurry and totally forgot this..