Appdesigner Question: Is it possible for a user to reset a default value?

I have a GUI that has a editable text field which specifies a path. This field has a default value (e.g. '~/foo/'). Does app designer allow for a user to reset a default value so that it is recalled when the app is closed and reopened?

For example: Path field = '~/foo/' is not useful for the user and would prefer to have the Path field default to '~/bar/'. But instead of having to change '~/foo/' to '~/bar/' every time the app is opened, I would like to know if the user can reset that value and have it reflected in the app's source code

After some digging around it doesn't seem like this is possible; figured it couldn't hurt to ask here.

Let me know if my question needs clarification. Thanks

[Adam]

I generally use a simple user-editable text file for things like this if I want to give the user an option to change e.g. the default range of a slider or value of an edit box.

I create a file with whatever settings in and a simple string for each that tells the user who reads the file what it is (though I add comment lines anyway for some) and that I can read in from the file to initialise my edit box or slider just as I would read a hard-coded value from code.

Answer 1

[Christian Karcher]

Hey David,

before your question hits its second birthday, let me share my approach to this task:

I indirectly solve this by implementing two functions, app.loadState() and app.saveState() The purpose of these function is to save all relevant variables into an external matfile and reload them upon program start.

saveState only gets called via a "set default values" button or menu, loadState gets called in the startup fcn.

Here's a rough scetch of the code:

function startupFcn(app)
  try
    app.loadState;
  catch % if no default values have been set yet
    % set standard values here;
  end
end

function SetasdefaultButtonPushed(app, event)
  app.saveState;
end

function saveState(app)      
  state.TextArea.Value = app.TextArea.Value;
  state.SomeListBox.Value = app.SomeListBox.Value;
  state.myProperty = app.myProperty ;
  % [...]
  save('MyAppDefaultValues.mat','state');
end

function loadState(app)
  load('MyAppDefaultValues.mat','state');  
  app.TextArea.Value = state.TextArea.Value;
  app.SomeListBox.Value = state.SomeListBox.Value;
  app.myProperty = state.myProperty ;
  %[...]
end

Answer 2

[Stephen23]

"... allow for a user to reset a default value so that it is recalled when the app is closed and reopened?"

Simpler and more efficient solution: use persistent.

[Christian Karcher]

Not to sure about that. You would still require extra variables for each property and GUI element you wish to save and one would always create default values, which is not wanted in most applications (that I use)

[Stephen23]

"You would still require extra variables for each property and GUI element you wish to save..."

That would be a very verbose approach. Just use one structure.

"...and one would always create default values, which is not wanted in most applications..."

I don't see why this should require "always" creating any values. Create one persistent structure. Add fields as required, which contain the users "default" values. On opening, transfer those fields' data to the internal handles structure (or whatever relevant parameter structure), otherwise use the values from the startup code. Simply put, if the field does not exist then the value has no "saved" default, and handles retains its startup value. Remove the relevant fields if no longer desired to have a "saved" default. See fieldnames, rmfield, dynamic fieldnames, etc.

Not very complex at all, and using persistent is more efficient than your approach of saving/loading .mat files. In fact, what I proposed is really just the same as your answer, just without the .mat files.

[Jim McIntyre]

Persistent is fine, but if the user exits Matlab the persistent values are reinitialized.

If the user truly wants to save default values that will be retained between Matlab sessions, then the LoadState/SaveState approach is the way to go.

Answer 3

[Steven Lord]

One potential approach is to use custom settings. From that documentation page, "You can create custom settings to store and access your own data across sessions."

Let's say I want to store where I'm working as a setting:

s = settings;
addGroup(s, "Steve_settings");
s

s = 
  SettingsGroup with properties:

            driving: [1x1 SettingsGroup]
    drivingscenario: [1x1 SettingsGroup]
           Simulink: [1x1 SettingsGroup]
        kits_common: [1x1 SettingsGroup]
           database: [1x1 SettingsGroup]
             matlab: [1x1 SettingsGroup]
     Steve_settings: [1x1 SettingsGroup]
         roadrunner: [1x1 SettingsGroup]
        comparisons: [1x1 SettingsGroup]
           parallel: [1x1 SettingsGroup]

Note that s has a group Steve_settings (in addition to the ones defined by MathWorks.) Let's add OfficeLocation as a setting in that new group.

addSetting(s.Steve_settings, "OfficeLocation")

ans = 
  Setting 'Steve_settings.OfficeLocation' with properties:

          ActiveValue: <no value>
       TemporaryValue: <no value>
        PersonalValue: <no value>
    InstallationValue: <no value>
         FactoryValue: <no value>

I can set the PersonalValue property of that setting:

s.Steve_settings.OfficeLocation.PersonalValue = "Apple Hill";
s.Steve_settings.OfficeLocation

ans = 
  Setting 'Steve_settings.OfficeLocation' with properties:

          ActiveValue: "Apple Hill"
       TemporaryValue: <no value>
        PersonalValue: "Apple Hill"
    InstallationValue: <no value>
         FactoryValue: <no value>

fprintf("Currently Steve is working from %s.", s.Steve_settings.OfficeLocation.ActiveValue)

Currently Steve is working from Apple Hill.

If I were working from a different office temporarily I can override that setting temporarily:

s.Steve_settings.OfficeLocation.TemporaryValue = "Lakeside";
s.Steve_settings.OfficeLocation

ans = 
  Setting 'Steve_settings.OfficeLocation' with properties:

          ActiveValue: "Lakeside"
       TemporaryValue: "Lakeside"
        PersonalValue: "Apple Hill"
    InstallationValue: <no value>
         FactoryValue: <no value>

fprintf("Currently Steve is working from %s.", s.Steve_settings.OfficeLocation.ActiveValue)

Currently Steve is working from Lakeside.

When I'm no longer working from that office:

clearTemporaryValue(s.Steve_settings.OfficeLocation);
s.Steve_settings.OfficeLocation

ans = 
  Setting 'Steve_settings.OfficeLocation' with properties:

          ActiveValue: "Apple Hill"
       TemporaryValue: <no value>
        PersonalValue: "Apple Hill"
    InstallationValue: <no value>
         FactoryValue: <no value>

fprintf("Currently Steve is working from %s.", s.Steve_settings.OfficeLocation.ActiveValue)

Currently Steve is working from Apple Hill.

I'll let you experiment with this code outside MATLAB Answers to see that the settings persist across sessions.

[Jim McIntyre]

This is a good approach, but I don't think it'll work for all applications. My computer is in a corporate environment, and the Matlab settings are stored in a directory that I'm not authorized to write to (frustrating, but true). The approach of using the external M file for setting has the advantage that the settings file can be stored in the same directory as the script.