octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #49143] inputdlg processes 2 element row vecto


From: Nicholas Jankowski
Subject: [Octave-bug-tracker] [bug #49143] inputdlg processes 2 element row vector rowscols input as heights instead of height and width
Date: Wed, 18 Oct 2023 16:57:01 -0400 (EDT)

Follow-up Comment #18, bug #49143 (project octave):

update to the bug report indicated that this issue had been fixed in R3032b. 
looking at the online documentation, the variable 'dims' is now called
'fieldsize', and the comment #13 text now states:


Text edit field height and width, specified as a scalar, vector, or matrix.

* If fieldsize is a scalar, then it specifies the height for all edit fields
in lines of text. The width for all edit fields is the maximum that the dialog
box allows.

* If fieldsize is a column or row vector with number of elements equal to the
number of prompts, then each element specifies the height of each
corresponding edit field from the top to the bottom of the dialog box. The
width for all edit fields is the maximum that the dialog box allows.

* If fieldsize is an m-by-2 matrix with m equal to the number of prompts, then
each row refers to the size of the edit field for the corresponding prompt.
The first column specifies the height of the edit field in lines of text. The
second column specifies the width of that edit field in character units. The
width of a character unit equals the width of the letter x when using the
system font.


the colormap example has been changed to have a 2 row input:


prompt = {'Enter matrix size:','Enter colormap name:'};
dlgtitle = 'Input';
fieldsize = [1 45; 1 45];
definput = {'20','hsv'};
answer = inputdlg(prompt,dlgtitle,fieldsize,definput)


that produces the same output as octave.

however all of the comment #13 examples produce the same output in matlab
2023b. the ambiguous 1x2 dim input is still ambiguous between the two input
formats, and arbitrarily follows option 3 while octave follows option 2. (one
would think the options would match the precedence order, but apparently it
doesn't.)

so they haven't changed behavior, just changed the example highlighting the
ambiguity, but the ambiguity still exists.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?49143>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]