Asking user is they want to save matrix to text file.

I have a program that generates a matrix based on user inputs called T and I'm trying to ask the user if they would like to save this matrix to a text file. If they do I want the file name to be specified by the user. If they don't want to save it, the program can just end. Here is what I have so far:

text = menu('Would you like to save data to a text file?','Yes','No');
if text == 1

[Walter Roberson]

That looks okay so far, except I would recommend using a different variable name so you do not interfere with using the text() function

Answer 1

[dpb]

While the above will work, menu has been deprecated; perhaps use questdlg instead...

option=questdlg('Save to text file?', ...
                'Save File',...
                'Yes', 'No','Yes');
% Handle response
switch option
  case 'Yes'
    fn=uiputfile(...       % call the savefile dialog if 'yes'
  case 'No'               
    return                 % nothing left to do, maybe...
end

Altho I'm a more "get me to the point" kinda' guy and for my own use I'd just go ahead and call uiputfile straighaway; the user can always cancel. Of course, if is a less-experienced user, perhaps the extra step of coaching is better; that's purely personal choice...

[Walter Roberson]

The documentation for menu suggests listdlg() instead.

[Tanner Larkey]

So if I wanted to keep the menu based approach what would it look like?

[dpb]

Hmmm....wonder when that was modified; in R2016b it suggests dialog, not listdlg. listdlg is suitable for lists, not 'Yes/No' questions, though, as far as a typical UI.

The XXXdlg family simplified wrappers around the general dialog control are, imo, the logical set to use for just a modal popup GUI in the middle of the code without building a fullfledged GUI.

In this case I think a listdlg for the purpose would just look tacky besides being less easy to use...so while I suppose I can see the reason for the change in the doc, I think it leads the wrong way for the OPs particular usage...

$0.02, imo, ymmv, etc., etc., etc., ... heck, even input "works"

[Walter Roberson]

text = menu('Would you like to save data to a text file?','Yes','No');
if text == 1
  [filename, pathname] = uiputfile('Select an output file', '*.txt');
  if ~ischar(filename); break;  end %user cancel
  fullname = fullfile(pathname, filename);
  save(fullname, 'T', '-ascii', '-double');
end

[dpb]

Yeah, if one isn't concerned about the TMW warning (clarification: "documentation user note" --dpb), other than being a little outdated in appearance it's as simple as it comes for interaction altho a user can ^C and abort with it whereas the user dialogs are modal and won't abort the script/function except by interaction. Of course menu would put up a text menu in the command window on old systems w/o graphics monitor, too... :)

[dpb]

Tanner; there's essentially no difference; one returns number, the other the string but that's just what one uses for the comparison/test of which was the selected option. The code in the CASE of the above answer would look like what Walter supplied.

The biggest negative I see with menu is the aforementioned fact your user can abort out either on purpose or by accident; the latter perhaps costing them quite a bit of effort...from command line try

>> opt=menu('Would you like to save data to a text file?','Yes','No')
Operation terminated by user during menu>local_GUImenu (line 271)

In menu (line 43)
  k = local_GUImenu( xHeader, ArgsIn ); 
>>

The questdlg won't do that...it'll wait for a response forever.

One other trivial little nicety in appearance is that there's a Title for the window whereas you just get "MENU" on the menu dialog and that's it...but, in the end it's your choice; either works and there's essentially no chance TMW will remove menu any time "realsoonnow"

[Walter Roberson]

menu() does not produce a warning, at least not up to R2018a.

[dpb]

ADDENDUM Ah! The "warning" was simply commenting on the phrase in the doc; not that it actually produces a warning message...I didn't connect the above comment until just now...

[Walter Roberson]

So? questdlg() can be closed by clicking on the x ?

^C should interrupt anything. It should interrupt questdlg too. And indeed in my test if you focus on the command window, control-C, click to focus on the command window again, and control-C again, then

Operation terminated by user during uiwait (line 81)

In questdlg (line 428)
    uiwait(QuestFig);

For the point about ^C to have any relevance, questdlg would have to prevent that too.

[Tanner Larkey]

Thanks for the help! Works great! I went with the menu based one just because that wasn't new to me (I'm quite the amateur at writing scripts if you couldn't tell). I'm sure there are much more efficient ways to do it, but this is just what's most comfortable right now.