Finding the 'current' dialog

[zarkzervo]

I have a QMainWindow with a toolbar with a toolbutton that I use to open a custom assistant for providing context relevant help to the user.

This is a scenario I want to achieve: The user has opened several tools and is currently inputing a value into a spinbox, but wonders what this tool/dialog really does. He presses the questionmark on the main window's toolbar and gets the helpfile for the dialog he is using.

Can someone help me find an elegant way of finding which dialog that currently has focus?

I see that a spinbox in the current tool still has focus and I can get that by:

QApplication::focusWidget();

QApplication::focusWidget();

To copy to clipboard, switch view to plain text mode 

If I try this:

QApplication::focusWidget();

QApplication::focusWidget();

To copy to clipboard, switch view to plain text mode 

, I get the main window.

I planned to get the current dialog and then use the objectName() to identify which helpfile to open.

I see it as risky business to implement code in all dialogs to try to traverse up to the top parent for that dialog as you are not forced to provide the parent in a constructor. But if nothing else works, I will do that and rather show a default help file if the top dialog for that particular focus widget is not known.

[Lykurg]

I see that a spinbox in the current tool still has focus and I can get that by:

QApplication::focusWidget();

QApplication::focusWidget();

To copy to clipboard, switch view to plain text mode 

If this is always true - I don't know - you can use parent() till you reach the "QDialog" class and get its object name.

[janus]

Hi,

just an idea:
maybe installing an eventfilter and checking the focus events might help.

[faldzip]

Maybe use "What's this?"? It requires 1 more click: User clicks on what's this button and then clicks on the widget he want to get some info about and it appears in some kind of tooltip.

[zarkzervo]

Thanks all.

I went for this solution:
After I created a tool that I wanted to have some help available for, I registered it in a central help object with its "parentPath" and the name of the helpfile I wanted to associate it with.

The parentPath, I found by connecting the objectName() of all the ancestors. This key would uniqely identify the help file to open for that object. This allows for more detailed help files further down the hierarchy.

When I wanted to open a help file, I simply used the focusWidget() widget and built the parentPath from that. I opened the helpfile with the longest parentPath that still fit with the parentPath:

":BOCS__Main::qt_workspacechild:ConfigureDlg:cmbB_ mode" would open the helpfile associated with ":BOCS__Main::qt_workspacechild:ConfigureDlg" and when I focus on a widget with more detailed help: ":BOCS__Main::qt_workspacechild:ConfigureDlg:split ter:groupBox_2:cmbB_stratType" it would open the file associated with ":BOCS__Main::qt_workspacechild:ConfigureDlg:split ter:groupBox_2:cmbB_stratType"

It may not be the most elegant solution, but it works and would always come up with a helpfile as it traverses back up the ancestry tree until it would probably find some smaller file or just open the default helpfile for the application.

One problem though: When you create a dialog and put it in the workspace, you automatically give away the ownership and the parentPath will change, e.g., the qt_workspacechild-part in my example. I therefore don't register the dialogs in their constructor, but rather call a registerHelp() after the dialog is shown.

This opens for detailed help associated with a single widget anywhere in my system, e.g. a more elaborate help for my "execute"-button as well as automatically opening the most detailed help for a widget.

There probably are endless problems that can occur, but as long as I'm aware of how it works, I can probably prevent most strange problems from happening.

[zarkzervo]

Maybe use "What's this?"? It requires 1 more click: User clicks on what's this button and then clicks on the widget he want to get some info about and it appears in some kind of tooltip.

I just wanted to say that I use whatsThis already.

I use the Qt Assistant system for more elaborate help and that allows for standard html files.

IMHO, more programmers should use whatsThis. I often need a little bit of help in an application and pressing help in many applications just opens the root help file and you have to search for what you're after.

[aamer4yu]

You could override WhatsThis event and show your custom help... cant you ?
It wud be much simpler I guess

[zarkzervo]

Personally, I don't think that is too smart as it would remove the main use of whatsThis and the user would expect something else than an elaborate help application from it.

And as I already use the whatsThis for its original purpose, I couldn't really reassign the use.