–Loren

disp('Loading Previous Workspace...')
load matlab.mat;

I then have a corresponding finish.m:

disp('Saving Current Workspace...')
save matlab.mat;

This way I have a persistent workspace and can always continue where I left off

You should contact technical support and supply with with everything they need to run your script. You can reach support via the link on the right of this blog.

–Loren

It seems like I can’t call a script from startup and have it operational for a long time.

startup.m

to set up my programming environment. I call EditorMacro.m (available off of mathworks.com> to set up a number of keybindings to matlab scripts that I use as part of my programming workflow. I also CD to the directory of the project I’m working on.

I also use it to set the MATLABROOT environment variable to correspond to the version of Matlab that has just been invoked.

I use this environment variable in Makefiles for S-function builds. This allows using the same Makefile for use with multiple Matlab versions without manual editing of the Makefile.

This requires the use of the setx utility from Microsoft’s “Windows XP Service Pack 2 Support Tools” which allows setting system environment variables. The support tools pack can be downloaded from:

http://www.microsoft.com/downloads/details.aspx?FamilyID=49ae8576-9bb9-4126-9761-ba8011fabf38&DisplayLang=en

Here is the operative portion of my startup.m:

% Turn grid lines on by default
set(0, 'defaultAxesXGrid', 'on')
set(0, 'defaultAxesYGrid', 'on')
set(0, 'defaultAxesZGrid', 'on')

% Set the MATLABROOT environment variable if it is not set correctly or
% it does not exist
if (~isequal(getenv('MATLABROOT'), matlabroot))
    fprintf('Updating MATLABROOT environment variable\n\n');
    result = dos(['setx MATLABROOT "' matlabroot '"']);
    if (result ~= 0)
        fprintf(['\nError setting MATLABROOT environment variable.  ', ...
            'You may not have the setx utility installed.\n'...
            'See the help below:\n\n']);
        help startup
    end
end
clear result

-Les

The setting of defaults is documented in one place for all of graphics. It’s not specific to any of the graphics primitives, but appropriate for all of them. I’m guessing the thinking was that it would bloat the documentation to mention setting different defaults in each FRP. But I will pass along your thoughts on this.

O is indeed the root level.

Thanks for your thoughtful comments on the documentation. Again, I will pass them along.

–Loren

Here is my question: Why isn’t this capability default setting capability mentioned in the FRP for grid? Instead, it is buried 3 layers deep in the general discussion of Graphics.

Also, what does it mean when the 1st example sets a default for the gcf, while a few lines later is says, “It is meaningful to specify a default figure color only on the root level.”? In your example, I guess you are setting grid to on at the root level, assuming that a handle value of 0 is the same as the root level.

Once I found the appropriate page of documentation, I did a search for “Defining Default Values,” and the 1st search result that was returned was under the broad topic of Object-Oriented Programming. This documentation miss-directed me in that the style for setting default values in the world of OOP is different than the world of Handle Graphics.

Let me turn this around a bit: List the series of documentation that I needed to read so I could have learned all I needed to know to generate your above command just from reading the documentation.

By the way, this encounter with the non-FRP documentation took me to the nice hot-link populated tree discussing Handle Graphic Object Properties. This section of documentation illustrates very strongly the shortcoming & complexity of MatLab’s graphic process.