Unexpected outcomes when using msgbox, warndlg, errordlg, and helpdlg

I’m trying to use msgbox, warndlg, errordlg, or helpdlg to warn users that they have chosen an option from the main menu that has no data loaded for that particular option.
h=warndlg(["Solar data not loaded for - " yearmon],“chooseplotSOLARday”);

The box opens, and the message at title are correct, but execution immediately continues and the main menu (a listdlg) is redrawn on top of the msgbox.

Going back to the msgbox and clicking OK does nothing. The dialog stays on screen until a valid main menu selection is made. If I try and use the “modal” option, then it locks up and I have to kill octave with Task Manager.

The only dlg function that works as expected is questdlg, which halts execution and awaits a response before returning to the main menu.
h=questdlg(["Solar data not loaded for - " yearmon],“chooseplotSOLARday”,“OK”,“Got It”,“OK”);

One thing I noticed is that all the problem functions appear in a “java-esque” format while questdlg looks more like an OS dialog. Pictures attached.

Is it reasonable for me to expect msgbox and the others to halt execution until the user responds with OK? Even so, the OK is not working, so I currently cannot use them.

I’m running Octave 5.2.0 X86_64-w64-mingw32 on a windows 10 machine build 19041.867
questdlg warndlg

Have you tried to use uiwait?

h=warndlg(["Solar data not loaded for - " yearmon],"chooseplotSOLARday");
1 Like

Thanks for the solution - it works entirely as expected.
The voyage of discovery continues. I wonder if it might be useful to include uiwait in the see also line of the manual entries for the *dlg functions.

That’s because the listdlg window is itself modal, i.e. you cannot do anything in other windows (including the msgbox) until the listdlg window is closed.

What do you mean by “locks up”? Hitting the OK button does nothing?

FWIW, on linux, when using the "modal" option with the GUI (or with a Qt figure) open, the dialog stays on top of all other windows until you hit the OK button and it dissapears, as expected for a modal dialog. So in practice, if things worked correctly, there would be no need for uiwait.

I tried the following script in Matlab:

errordlg('Test', 'Test', 'modal');


Hello” is printed on the command line before I close the dialog.
If something different is happening on Linux with Octave, that might be a bug.

It works the same way in Octave on linux: you can still have the interpreter execute code (like disp ('hello')), but you cannot interact with any other GUI window than the dialog.

Ah thanks for clarifying. I understood you expected the same behavior for a modal dialog like for a dialog with uiwait.

For the purpose of clarity (I hope): the "modal" option for the msgbox and the use of uiwait afterward are complementary (and not equivalent as I previously said). The former prevents the user from interacting with any other GUI window than the msgbox (but still gives control back to the interpreter), while the latter blocks further execution of code being run, which is actually what this post was about.

So what I said

is wrong and adding uiwait in the see also list would probably be a good idea.

Just to clear things up - I use a listdlg as my main menu which is in a loop that calls a script or function corresponding to the select line, then loops around again for the next choice. After making a selection the listdlg disappears, and if no data is loaded, I use a msgbox to alert the user.
Without uiwait, the message box is drawn and immediately after that the main menu is redrawn. If I move the listdlg to one side to expose the msgbox and I click OK, nothing happens - but the main menu still works.
If I set the msgbox to “modal” then I can’t even execute the main menu and I have to kill the gui using Task Manager (CTRL-C didn’t work).
With uiwait, the msgbox is drawn and the system waits for the user’s response, then the main menu is redrawn and we await the next menu selection.
The uiwait function has solved the problem - I’m happy :slight_smile: