bugGNU Octave - Bugs: bug #42490, helpdlg does not return a proper...


bug #42490: helpdlg does not return a proper graphics handle

Submitted by:  Hartmut <hardy>
Submitted on:  Mon 02 Jun 2014 01:36:18 PM UTC  
Category:  Plotting Severity:  3 - Normal
Priority:  1 - Later Item Group:  Matlab Compatibility
Status:  Postponed Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  Any

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Wed 10 Feb 2016 07:45:03 AM UTC, comment #6:

FYI, if code is still in the state I think it is, the Qt dialog code is something I wrote, and it was not initially intended to be a full-blown implementation of handles or whatnot for reasons of limitations. Also, the dialogs have to be modal because of this limitation. The limitation at the time was the lack of a well-designed cross-thread communication between Octave core and whatever GUI it is running in. Without that, about all that can be done is suspend the Octave core while the GUI dialog is responded to, return the answer, then take the core out of sleep state and read the result. Having a good cross-thread comm where commands and results can be exchanged would solve not only this problem, but make breakpoints and such easy as well.

Dan Sebald <sebald>
Wed 04 Jun 2014 01:24:22 AM UTC, comment #5:

The octave_link variant does bring up a Qt dialog box instead. But the same bug is present, the value returned is always 1, not a valid handle to the dialog box.

The matlab help pages for helpdlg and the other dialog functions also says that the windows should be non-modal by default, returning control to the interpreter while the dialog is still up.

Mike Miller <mtmiller>
Project Administrator
Tue 03 Jun 2014 08:08:18 PM UTC, comment #4:

In the mean time I saw that <scripts>/..../gui/private/message_dialog.n can also call _octave_link_message_dialog_ (in libinterp/corefcn/octave-link.cc). So Java doesn't have to be invoked at all to produce dialog windows.

Makes me wonder what graphics subsystem is invoked by octave_link() (OpenGL?) (I quickly got lost in the octave_link.h file). After all a graphics dialog window is produced, so there must be a window handle somewhere. (But then maybe one w/o usable public methods.)

So, in the end I suppose a fix would require quite a bit of overhaul that could better wait until Qt dialog and more ui* functions have been implemented in a structured way.

The Java variants might be patched then to return a Java window handle - also needs some overhaul. But that would yield some closer "ML compatibility" (i.e., Java based that is)

Philip Nienhuis <philipnienhuis>
Project Member
Tue 03 Jun 2014 07:39:19 PM UTC, comment #3:

That was my thinking too. I believe eventually Octave can do this with the Qt toolkit, so I've marked this as postponed until some time after 4.0.

Rik <rik5>
Project Administrator
Tue 03 Jun 2014 07:17:36 PM UTC, comment #2:

As far as helpdlg.m (and its other *dlg siblings) is concerned, they currently produce Java-based windows. I wonder if Octave's ui.... functions would be able to deal with Java window handles anyway.

AFAIU Matlab's GUI was Java-based so it made more sense there to return a Java window handle. (I'm not sure about the GUI of ML's recent versions though.)

Maybe this bug can be attacked once Qt-based *dlg functions are implemented. Should this bug report be marked as "postponed" and/or "feature request" until then?

Philip Nienhuis <philipnienhuis>
Project Member
Mon 02 Jun 2014 03:42:42 PM UTC, comment #1:

Confirmed. This seems to be a general incompatibility with the *dlg functions. It does not appear that they were ever coded with the intent of returning a graphics handle.

Rik <rik5>
Project Administrator
Mon 02 Jun 2014 01:36:18 PM UTC, original submission:

This behavior is fully documented in the Octave doc. But it is incompatible to Matlab.

Here is an (artificial) example that works under Matlab and does not under Octave:

The difference seems to be that

  • helpdlg does NOT return a proper graphics handle of its own window, but always returns the value 1 (as is said in the manual)
  • uiwait can only work with proper graphics handles (which is fine, but generates an error message in this case)
Hartmut <hardy>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

   bug dependencies.


Carbon-Copy List
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by hardy (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-04-27 mtmiller Priority5 - Normal => 1 - Later
        Release3.8.1 => dev
    2016-02-11 rik5 Carbon-CopyRemoved 72865 => -
    2016-02-05 pantxo Dependencies- => bugs #47056 is dependent
    2014-06-03 rik5 StatusConfirmed => Postponed
    2014-06-02 rik5 StatusNone => Confirmed

    Back to the top

    Powered by Savane 3.3