Important: Please read the Qt Code of Conduct -

Best way to access user help for small application

  • I have developed a small Qt staff rota application that has a number of modal dialogs driven from a menu. Each staff member has various information associated with them would prefer to work any two consecutive days per week or would like two Saturdays off a month. After the rota has been generated by the application it allows the user to do various modifications to the result (move people around etc). I wanted to be able to display in a separate window or dialog box a Combo box (to choose a staff member) and a text box to display a couple of lines of details about the working habits of that staff member (to help the user)
    Because the application has modal dialog boxes (which I like) I am not sure where or how best to display this information. Because what I am displaying is so simple I though that I should simply use a modeless dialog that I make visible when and as needed. However when I create the modeless dialog box in the main window and later select a modal dialog box I can no longer interact with the modeless dialog box(cant select staff members). I thought of using Qt help framework or qWebView, but they seemed over the top for what i wanted to do. I could possibly kick off a separated Qt dialog application(or thread) that does what I need (and control its visibility from the main program).
    Whats the best way of doing this (and allowing the user to get information about a staff member at any time within the application)?
    Anyone have any thoughts on this?

  • @Phil1864 said in Best way to access user help for small application:

    However when I create the modeless dialog box in the main window and later select a modal dialog box I can no longer interact with the modeless dialog box(cant select staff members).

    I think you can rescue your modeless-dialog-which-is-always-visible approach, which may be as good as any and which is simple.

    When you create QDialogs there is an optional parent parameter. This determines (apart from other things) what gets "blocked" by dialogs. Be careful to make it so all your modal dialogs specify the invoking dialog or main window for this, while your modeless dialog specifies nullptr. This will make your modeless "application modeless" while your modals are "window modal". You should find your dialogs block each other and the main window, while your modeless is always available to see/interact with. You should also confirm this behaviour on other platforms if you support them.

  • Thanks JonB for your suggestion. It looked exactly what I needed. I am running under Linux and unfortunately it did not seem to work. I created the modeless dialog in my mainwindow with a NULL parent parameter and displayed it. I then select a modal dialog and this blocks me from the modeless dialog.
    What could I be doing wrong? Would this method work on windows?
    Thank again for your help.

  • @Phil1864
    But did you verify that your complete chain of the modal dialogs do specify some parent each time, never NULL? As soon as any one of them specifies NULL they become application modal instead of window modal, and then your modeless will get blocked even if that specifies NULL.

  • Thank You again for your time and help. I cant see anywhere that I dont pass the parent parameter, other then the modeless dialog that I needed for the staff details. In the end I used QProcess to start a separate process to enable the staff details to be loaded and modified. I then use QProcess->terminate() to close that process (both Unix and windows) and catch(signals in unix) any edits. I preferred your solution, it would have been much simpler, but this was not to bad in the end and seems to work well.
    Thank You so much again. If I get time I will experiment with your suggestion again. Thank You.

Log in to reply