bugGNU Octave - Bugs: bug #49734, uimenu's position is sometimes 0

 
 

bug #49734: uimenu's position is sometimes 0

Submitted by:  Guillaume <gyom>
Submitted on:  Tue 29 Nov 2016 10:52:35 AM UTC  
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Confirmed Assigned to:  None
Originator Name:  Guillaume 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)

Fri 02 Dec 2016 03:19:41 PM UTC, comment #9:

@Pantxo: position now returns 1 when it was returning 0.
Unfortunately, Octave now segfaults with this:

Guillaume <gyom>
Fri 02 Dec 2016 12:51:06 PM UTC, comment #8:

I attached a patch for testing.

(file #39131)

Pantxo Diribarne <pantxo>
Project Member
Fri 02 Dec 2016 12:22:11 PM UTC, comment #7:

@Markus: I don't think following Matlab here is a good idea, if 0 is an incorrect value what is the point of displaying a warning when we trigger an error for other incorrect values?
More important I think is having the upper value right: this means that we need to define a custom uimenu::set_position which checks the number N of uimenus in the parent object and error out if the requested value is greater than N.

The position property is updated by the graphics_toolkit but setting it in uimenu.m is probably the best solution. Something like

Pantxo Diribarne <pantxo>
Project Member
Fri 02 Dec 2016 11:11:21 AM UTC, comment #6:

That's right, the patch only changes the limit check.
I do not know where the menus are created and maintained. It is not in graphics.cc. If someone could give a hint as to where this happens, I might be able to provide patches for the remaining two issues:

  • Emit a warning when position == 0 and do nothing. (Might be easy.)
  • Update the position property early on uimenu object creation. (I have no idea where and how these objects are created. So it might be [very] hard to implement.)
Markus Mützel <mmuetzel>
Project Member
Fri 02 Dec 2016 10:42:21 AM UTC, comment #5:

Thanks Markus. So now, Octave returns an error when position is < 0 and creates a menu in the last position if position is 0 or > N (Matlab displays a warning and do nothing). I'm OK with this behavior. The initial issue of position being 0 when queried remains.

Guillaume <gyom>
Thu 01 Dec 2016 06:36:58 PM UTC, comment #4:

I just checked in Matlab and it does emit a warning when position is set to 0 and an error for anything < 0. The attached patch changes the limits check to be Matlab compatible.
Fwiw, I also checked all the other properties for which limits checks have been recently added. They seem to behave consistently with Matlab.

(file #39128)

Markus Mützel <mmuetzel>
Project Member
Thu 01 Dec 2016 12:22:52 PM UTC, comment #3:

Hi Pantxo, thanks for the explanation. I now understand why the error only started occurring recently (note that this is an error and not a warning).

Matlab returns the correct value straight away:

If a figure has N menus, the allowed values in Matlab for position when creating a new menu are 1:N+1. In Octave, they are 1 to Inf where any value greater than N+1 is set to N+1.

Also, I tried with drawnow but it does not work.

Guillaume <gyom>
Thu 01 Dec 2016 11:54:49 AM UTC, comment #2:

Hi Guillaume,

The size, and thus the position vector of a uimenu may only be known by the interpreter once it has been drawn. When run in a script drawnow is only executed at the end of the script, when returning to prompt. Pause has the effect to trigger drawnow (try with drawnow, it should work also).
Does ML have the position right before returning to prompt?

As for the warning when you try to set an incorrect value for position, it is due to a recent cset that added input checking:
http://hg.savannah.gnu.org/hgweb/octave/rev/96228c17a66a

Pantxo Diribarne <pantxo>
Project Member
Thu 01 Dec 2016 10:35:19 AM UTC, comment #1:

Does anyone else reproduce this? It has to be a script that is executed and not copy-pasted. I get a position of 0 with both Octave 4.2 and with the latest dev version.

I didn't noticed this before as 4.2 treats a zero position as if none was specified (and the menu is put at the last position):

Octave 4.3+ (rightfully) complains about it:

(Matlab displays a warning "Warning: Invalid uimenu position - not rendering").

I wonder if the change that now triggers the error is related to the fix in bug #48255. That said, the issue is that the following should never return 0:

Guillaume <gyom>
Tue 29 Nov 2016 10:52:35 AM UTC, original submission:

If you try to immediately access the position property of a newly created uimenu, it sometimes returns 0. The correct value is returned if a pause statement is added between the creation of the uimenu and the get('position') query.

To reproduce the issue, create a script containing:

Executing the script from the Octave prompt often returns 0. If you uncomment the pause statement, the position will be 1.

(note that, as pointed out in bug #44672, the already existing menus of a figure (File, Edit, Help) are not 'visible' as the position of the newly created menu item should be 4 and not 1.

Guillaume <gyom>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #39131:  uimenu_position.patch added by pantxo (2KiB - text/x-diff)
file #39128:  bug49734_limit_check.patch added by mmuetzel (767B - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Updated the item)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by gyom (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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-12-02 pantxo Attached File- => Added uimenu_position.patch, #39131
    2016-12-01 mmuetzel Attached File- => Added bug49734_limit_check.patch, #39128
    2016-12-01 pantxo StatusNone => Confirmed

    Back to the top


    Powered by Savane 3.4