Archive for October, 2009

uiundo – Matlab’s undocumented undo/redo manager

Thursday, October 29th, 2009

Whenever we have a Matlab GUI containing user-modifiable controls (edit boxes, sliders, toggle buttons etc.), we may wish to include an undo/redo feature. This would normally be a painful programming task. Luckily, there is an undocumented built-in Matlab support for this functionality via the uiundo function. Note that uiundo and its functionality is not Java-based but rather uses Matlab’s classes and the similarly-undocumented schema-based object-oriented approach.

A couple of months ago, I explained how to customize the figure toolbar. In that article, I used the undocumented uiundo function as a target for the toolbar customization and promised to explain its functionality later. I would now like to explain uiundo and its usage.

The uiundo function is basically an accessor for Matlab’s built-in undo/redo manager object. It is located in the uitools folder (%MATLABROOT%\toolbox\matlab\uitools) and its @uiundo sub-folder. To use uiundo, simply define within each uicontrol’s callback function (where we normally place our application GUI logic) the name of the undo/redo action, what should be done to undo the action, and what should be done if the user wished to redo the action after undoing it. uiundo then takes care of adding this data to the figure’s undo/redo options under Edit in the main figure menu.

For example, let’s build a simple GUI consisting of a slider that controls the value of an edit box:

hEditbox = uicontrol('style','edit', 'position',[20,60,40,40]); 
set(hEditbox, 'Enable','off', 'string','0');
hSlider = uicontrol('style','slider','userdata',hEditbox);
callbackStr = 'set(get(gcbo,''userdata''),''string'',num2str(get(gcbo,''value'')))';
set(hSlider,'Callback',callbackStr);

Simple GUI with slider update of a numeric value

Simple GUI with slider update of a numeric value

Now, let’s attach undo/redo actions to the slider’s callback. First, place the following in test_uiundo.m:

% Main callback function for slider updates
function test_uiundo(varargin)
 
  % Update the edit box with the new value
  hEditbox = get(gcbo,'userdata');
  newVal = get(gcbo,'value');
  set(hEditbox,'string',num2str(newVal));
 
  % Retrieve and update the stored previous value
  oldVal = getappdata(gcbo,'oldValue');
  if isempty(oldVal),  oldVal=0;  end
  setappdata(gcbo,'oldValue',newVal);
 
  % Prepare an undo/redo action
  cmd.Name = sprintf('slider update (%g to %g)',oldVal,newVal);
 
  % Note: the following is not enough since it only
  %       updates the slider and not the editbox...
  %cmd.Function        = @set;                  % Redo action
  %cmd.Varargin        = {gcbo,'value',newVal};
  %cmd.InverseFunction = @set;                  % Undo action
  %cmd.InverseVarargin = {gcbo,'value',oldVal};
 
  % This takes care of the update problem...
  cmd.Function        = @internal_update;       % Redo action
  cmd.Varargin        = {gcbo,newVal,hEditbox};
  cmd.InverseFunction = @internal_update;       % Undo action
  cmd.InverseVarargin = {gcbo,oldVal,hEditbox};
 
  % Register the undo/redo action with the figure
  uiundo(gcbf,'function',cmd);
end
 
% Internal update function to update slider & editbox
function internal_update(hSlider,newValue,hEditbox)
  set(hSlider,'value',newValue);
  set(hEditbox,'string',num2str(newValue));
end

And now let’s point the slider’s callback to our new function:

>> set(hSlider,'Callback',@test_uiundo);

Undo/redo functionality integrated in the figure

Undo/redo functionality integrated in the figure

We can also invoke the current Undo and Redo actions programmatically, by calling uiundo with the ‘execUndo’ and ‘execRedo’ arguments:

uiundo(hFig,'execUndo');
uiundo(hFig,'execRedo');

When invoking the current Undo and Redo actions programmatically, we can ensure that this action would be invoked only if it is a specific action that is intended:

uiundo(hFig,'execUndo','Save data');  % should equal cmd.Name

We can use this approach to attach programmatic undo/redo actions to new toolbar or GUI buttons. The code for this was given in the above-mentioned article. Here is the end-result:


Undo/redo functionality integrated in the figure toolbar

Undo/redo functionality integrated in the figure toolbar

Undo/redo functionality integrated in the figure toolbar


In my next post, due next week, I will explore advanced customizations of this functionality.

Accessing the Matlab Editor

Monday, October 19th, 2009

Matlab’s built-in editor, like most other Matlab GUI, is Java-based. As such, it can easily be accessed programmatically. ImageAnalyst, a well-respected member of the Matlab community and a frequent CSSM (newsgroup) and FEX (File Exchange) contributor, recently asked whether it is possible to retrieve the name of the Editor’s currently edited file. The answer is that this is very easy, but I decided to use this opportunity to show how other interesting things can be done with the Editor.

Before we start, it should be made clear that this entire article relies on MathWorks internal implementation of the Editor and Desktop, which may change without prior notice in future Matlab releases. The code below appears to work under Matlab 6 & 7, but users who rely on forward compatibility should be aware of this warning.

We start by retrieving the Editor handle. This can be done in a number of ways. The easiest is via the Matlab desktop:

try
    % Matlab 7
    desktop = com.mathworks.mde.desk.MLDesktop.getInstance;
    jEditor = desktop.getGroupContainer('Editor').getTopLevelAncestor;
    % we get a com.mathworks.mde.desk.MLMultipleClientFrame object
catch
    % Matlab 6
    % Unfortunately, we can't get the Editor handle from the Desktop handle in Matlab 6:
    %desktop = com.mathworks.ide.desktop.MLDesktop.getMLDesktop;
 
    % So here's the workaround for Matlab 6:
    openDocs = com.mathworks.ide.editor.EditorApplication.getOpenDocuments;  % a java.util.Vector
    firstDoc = openDocs.elementAt(0);  % a com.mathworks.ide.editor.EditorViewContainer object
    jEditor = firstDoc.getParent.getParent.getParent;
    % we get a com.mathworks.mwt.MWTabPanel or com.mathworks.ide.desktop.DTContainer object
end

Now that we have the Editor handle, let’s retrieve its currently open (active) file name from the Editor’s title:

title = jEditor.getTitle;
currentFilename = char(title.replaceFirst('Editor - ',''));

The entire list of open file names can be retrieved in several ways:

% Alternative #1:
edhandle = com.mathworks.mlservices.MLEditorServices;
allEditorFilenames = char(edhandle.builtinGetOpenDocumentNames);
 
% Alternative #2:
openFiles = desktop.getWindowRegistry.getClosers.toArray.cell;
allEditorFilenames = cellfun(@(c)c.getTitle.char,openFiles,'un',0);

At the top-level Editor-window level, we can prevent its resizing, update its status bar, modify its toolbar/menu-bar, control docking and do other similar fun things:

% Actions via built-in methods:
jEditor.setResizable(0);
jEditor.setStatusText('testing 123...');
jEditor.setTitle('This is the Matlab Editor');
 
% Equivalent actions via properties:
set(jEditor, 'Resizable', 'off');
set(jEditor, 'StatusText', 'testing 123...');
set(jEditor, 'Title', 'This is the Matlab Editor');

Actually, the jEditor handle has over 300 invokable methods and close to 200 properties that we can get/set. Perhaps the easiest way to find interesting things we can programmatically do with the Editor handle, is to use my UIInspect utility on the File Exchange:

uiinspect(jEditor);  % or: jEditor.uiinspect
Matlab Editor methods, callbacks and properties as seen by uiinspect (click to zoom)

Matlab Editor methods, callbacks and properties as seen by uiinspect
(click to zoom)

The Editor handle is actually a container for many internal panels (toolbars etc.) and documents. The entire object hierarchy can be seen with another of my File Exchange utilities, FindJObj:

findjobj(jEditor);  % or: jEditor.findjobj
Matlab Editor object hierarchy as seen by findjboj (click to zoom)

Matlab Editor object hierarchy as seen by findjboj (click to zoom)

We can modify text within the open Editor documents, and instrument these document to handle event callbacks. To see how, I refer users to my EditorMacro utility on the Matlab File Exchange.

If you find some other nifty and/or useful things that can be done using the Editor handle, please post them in the comments section below.

Updating speaker sound volume

Thursday, October 15th, 2009

In a recent CSSM forum post, a reader asked whether it is possible to get and/or set the system speaker sound volume programmatically. The purpose would be to connect this programming snippet to a GUI control that would allow users to increase/decrease playback volume in the same GUI window as the other playback controls.

This is apparently not possible with documented Matlab functions: we can modify specific playback files, but not the speaker in general. However, it is possible using standard Java calls. Note that I am specifically not mentioning the word undocumented here. The reason is that these Java calls can all be achieved using Matlab’s documented, although mostly unknown, Java interface.

Today, I have submitted a new utility to the Matlab File Exchange, called SoundVolume. SoundVolume enables getting and setting the speaker volume programmatically. For the benefit of users, here is the core of the program (the actual program contains extra sanity checks and exception handling):

function volume = SoundVolume(volume)
 
   % Loop over the system's mixers to find the speaker port
   import javax.sound.sampled.*
   mixerInfos = AudioSystem.getMixerInfo;
   foundFlag = 0;
   for mixerIdx = 1 : length(mixerInfos)
      mixer = AudioSystem.getMixer(mixerInfos(mixerIdx));
      ports = getTargetLineInfo(mixer);
      for portIdx = 1 : length(ports)
         port = ports(portIdx);
         try
            portName = port.getName;  % better
         catch   %#ok
            portName = port.toString; % sub-optimal
         end
         if ~isempty(strfind(lower(char(portName)),'speaker'))
            foundFlag = 1;  break;
         end
      end
   end
   if ~foundFlag
      error('Speaker port not found');
   end
 
   % Get and open the speaker port's Line object
   line = AudioSystem.getLine(port);
   line.open();
 
   % Loop over the Line's controls to find the Volume control
   ctrls = line.getControls;
   foundFlag = 0;
   for ctrlIdx = 1 : length(ctrls)
      ctrl = ctrls(ctrlIdx);
      ctrlName = char(ctrls(ctrlIdx).getType);
      if ~isempty(strfind(lower(ctrlName),'volume'))
         foundFlag = 1;  break;
      end
   end
   if ~foundFlag
      error('Volume control not found');
   end
 
   % Get or set the volume value according to the user request
   oldValue = ctrl.getValue;
   if nargin
      ctrl.setValue(volume);
   end
   if nargout
      volume = oldValue;
   end

Note that our Matlab code could have been much simpler, following the examples provided here and here. Unfortunately, Matlab prevents using Java classnames containing a period (e.g., Port.Info) or static Interface values, so we cannot directly access Port.Info.SPEAKER or FloatControl.Type.VOLUME. I’ve reported this bug to Mathworks earlier this year, and I do not know in which Matlab release (if at all) they intend to fix it. Until then we need to use workarounds, as in the code above. I posted a similar issue (and its workaround) earlier in this blog, when setting system-tray popup message.

For more information about accessing Java’s extensive sound-related functionality, read Sun’s official Java sound documentation trail.

Performance: scatter vs. line

Wednesday, October 14th, 2009

Following my previous article on the undocumented behavior of the scatter function, one of my readers, Benoit Charles, reported a discovery that in many circumstances the line function generates identical plots much faster than scatter.

Unlike scatter, line does not enable specific data-point marker customization, although the colors could be modified. On the other hand, line only uses a single handle object, saving memory and system resources compared to scatter keeping a separate handle for each data point. So, if you just need to quickly plot a bunch of scattered points then line could be a better choice than scatter.

Here is a simple code snippet, which generates identical plots and shows the performance difference:

>> x=rand(1000,1); y=rand(1000,1);
 
>> tic, for idx=1:100, cla; h=scatter(x,y); end; toc
Elapsed time is 2.521322 seconds.
 
>> props = {'LineStyle','none','Marker','o','MarkerEdge','b','MarkerSize',6};
>> tic, for idx=1:100, cla; h=line([x,x],[y,y],props{:}); end; toc
Elapsed time is 0.333369 seconds.

In the past, I have posted about other undocumented performance aspects, comparing the documented ismember function with the undocumented ismembc and about cellfun’s undocumented options. If you are aware of other similar functions having identical outputs and a significant performance difference, please let me know.

Undocumented scatter plot behavior

Monday, October 12th, 2009

One of my blog readers, Henrik Toft, reported an undocumented behavior of the well-known scatter plot function: scatter returns a handle to an hggroup-type object that contains child handles of the data points (patch-type objects). This enables easy manipulation of specific points (for example, changing the color or marker of interesting data points).

The undocumented behavior is that when the scatter plot contains more than 100 points, the returned hggroup object only has a single child – a handle to a unified patch object that contains all the data points. This prevents customization of specific points: color can be customized via the cdata property, but this is not trivial; the marker cannot be customized at all.

Both Henrik and I initially thought this was a simple bug. But when Henrik reported this issue to MathWorks support, he got the response that this is indeed the expected behavior (i.e., not a bug but a feature), which is not documented. MathWorks did not say whether this was because they didn’t think users need more than 100 child handles, or perhaps an issue with memory/performance. Whatever the reason, I feel that this behavior/feature should at least be documented:

>> hggroup = scatter(rand(99,1),rand(99,1));
>> size(get(hggroup,'Children'))
ans =
    99     1
 
>> hggroup = scatter(rand(100,1),rand(100,1));
>> size(get(hggroup,'Children'))
ans =
   100     1
 
>> hggroup = scatter(rand(101,1),rand(101,1));
>> size(get(hggroup,'Children'))
ans =
     1     1

Workaround: use the ‘v6′ option. Unfortunately, this option is deprecated and marked as obsolete by Matlab, with the warning that it will be removed in a future Matlab version. I hope this will not be done until a better workaround for the above-reported issue is implemented in the scatter function:

>> hPatches = scatter('v6',rand(101,1),rand(101,1));
Warning: The 'v6' argument to SCATTER is deprecated, and will no longer be supported in a future release.
> In usev6plotapi>warnv6args at 84
  In usev6plotapi at 40
  In scatter at 39
 
>> size(hPatches)
ans =
   101     1

If you have detected any other undocumented behavior, function or feature in Matlab, please report them in the comments section below, or directly by email to me: altmany at gmail dot com.

uicontrol side-effect: removing figure toolbar

Wednesday, October 7th, 2009

Earlier versions of Matlab had an undocumented side-effect in the uicontrol function, of removing the figure toolbar if the figure’s toolbar property was set to ‘auto’ (which is the default value for figures).

In order to restore the toolbar, or prevent its removal in the first place, set your figure’s toolbar property to ‘figure’. This should preferably be done immediately after creating the figure, or in its *_OpeningFcn() function if the figure was created using GUIDE:

set(hFig,'toolbar','figure');

The uicontrol issue is now documented in the latest Matlab 7.9 release (R2009b), although it was undocumented for many earlier Matlab releases. Nevertheless, the current documentation, coupled with the fact that this issue was widely reported in the CSSM newsgroup and so is not really innovative, made me hesitate before posting. But I’m currently on vacation and don’t have time for a more detailed article this week (I skipped last week entirely), so I apologize to anyone who feels disappointed. I promise to compensate when I get back from vacation…

A similar issue was reported for GUIDE-created figures, and was reportedly solved in Matlab 7.2 (R2006a).