"I have 'DefaultFigureUnits' set to 'normalized' on my installation." - This is a bad idea which can and will cause unexpected behavior. It is strongly recommended not to change the Default-Properties, because this influences all other software also.
It is much safer to define your own defaults only, e.g.:
figure('Name', 'A test', ...
function Prop = myFigProps()
Prop.FigureUnits = 'normalized';
This is a small addition, which protects collisions with other projects. Imagine that you want to install a toolbox from someone else, which changes the Default properties also.
Changing the current folder by cd() just to call a specific function is a bad idea also. (Too) many software rely on the current folder to be at a specific place. Even a temporary change can influence e.g. callbacks of timers or GUIs. Prefer the function builtin() in your case.
Modifying the original code or creating a modified version and store it in a folder on top of the path are working reliably on your computer. But using your project code on another computer or installing 3rd party tools on your computer can cause collisions again.
So the reliable and clean solution is to leave the Default properties untouched, and use the above approach. Another option is to use a wrapper for the figure() command:
function H = myFig(varargin)
H = figure(varargin{:}, 'FigureUnits', 'normalized');
E.g. the command dialog() is such a wrapper, which adjusts all properties, which do not match dialog windows.
Using dedicated functions instead of modifying the Default properties is satble and safe. There are no collision with Matlab's built-in functions or 3rd party tools. In addition this is much easier to maintain and no workarunds are required to distinguish wanted from unwanted behavior.
But to answer the question: I do use modified built-in functions also. E.g. ind2rgb() can be accelerated massively without changing the behavior. My initialisation tool checks, if the current Matlab session uses the slow original version, and if so adds a folder on top of the path, which contains the faster version. But in this case there are no interferences with other functions.
And if any interferences would be possible, I choose another way. Remark:
- If a code is good, it will grow and will be used by others also. So start avoiding potential interferences with other platforms and new Matlab versions as good as possible. If a software has grown to 100'000 lines of code, fundamental changes are much more difficult or even impossible.
- If a code is not good - well, sigh, delete it or treat it as funny hack.
A very expensive software project between Lidl (a German supermarket chain) and SAP has failed after years of work, because it was impossible to adjust the different definitions of what the price of goods in the stock. For the SAP database it was the prie for buying, but for Lidl the current selling price in the sale matters. After 500 Million Euro have been spent, it got clear, that the difference cannot be solved.
I know, the example seems to be exaggerated, but it shows, that even professionals can and do loose the the overview of side-effects, when their program design include too many dependencies. Avoid collisions by using personal wrappers, if a personal behavior is wanted.
