If no graphics objects are added to or removed from a figure, does findobj always generate the list in the same order?

Hopefully my question is clear from the title, but I'll try to clarify what I mean.

Suppose I have a figure full of graphics objects and I want to gather all of these objects to perform some kind of function on each one.

hf = figure;
axes;
uicontrol;
hObjects = findobj(hf);
for i = 1:length(hObjects)
    foo(hObjects(i));
end

Now suppose this array of graphics objects goes out of scope but later on, I want to perform some other function on each of these objects.

hf = gcf;
hObjects = findobj(hf);
for i = 1:length(hObjects)
    bar(hObjects(i));
end

If I haven't added or removed any graphics objects from the figure (nor changed their Type), am I guaranteed the same list of objects from findobj? For example, if bar is the inverse function to foo in the sense that foo(bar(hObject)) == hObject is true for a given graphics object hObject, does the above code revert all my graphics objects to their original state in the end?

Thanks in advance for your answers!

Answer 1

[Walter Roberson]

If I haven't added or removed any graphics objects from the figure (nor changed their Type), am I guaranteed the same list of objects from findobj?

No.

uistack() can change the order of objects.

Making a figure current (such as by clicking on it) changes the order of objects -- I tested this for figures

I would not be at all astonished if making an object current by clicking on it, had the effect of raising it inside its container -- and likewise, its container inside the container of the container, and so on. Clicking a line probably moves the line to the top of its group, and moves the axes that the line is in to the top of its uipanel, and the uipanel to the top of its figure, and the figure to the top of the active figures. I have not tested this (only tested with figures), but it would not astonish me.

[Wouter Van Werveke]

Thanks a lot for your answer! My precise situation is as follows: I have some code for a GUI developed with GUIDE some years ago. When a certain button is clicked, a lengthy calculation is performed, during which I want to prevent any interaction of the user with the GUI, except for an "abort" button. For this purpose, I collect all the uicontrol objects in the figure using findobj, store their current Enable property and set it to 'off'. After the lengthy calculation is done, I go through the list again and reset their Enable properties to what they were before.

From my experience with it so far, this seems to perform the way I expect it to. The calculation doesn't involve any actual manipulations of the GUI objects such as uistack, and I assume clicking objects while their Enable property is set to 'off' doesn't make them current? Furthermore, the GUI window is the only figure open so it should be the current one at all times, but I will be wary of this if that ever changes.

Perhaps a modal dialog box with an abort button would be a simpler, more robust solution? However, that can be bypassed with Ctrl-C, if I'm not mistaken, and it would require hacking the Close button (X) in the top right corner of the box.

[Steven Lord]

Rather than calling findobj twice, why not use an onCleanup object to restore the original values of the properties when it is deleted (which could be when the function containing the onCleanup object completes)?

M = magic(6);
h = plot(M); % 6 line vectors
c = get(h, 'Color'); % 6 element cell array
set(h, 'Color', 'r'); % All lines become red
restoreLineColors = onCleanup(@() set(h, {'Color'}, c));
% Lines are still red
delete(restoreLineColors); % Lines go back to their original colors

You can't see the effect in Answers because I can't snapshot the appearance of the axes and graphics objects at each step, but if you run that code line by line in your MATLAB session you'll see the effects of the set call including when the onCleanup object gets deleted.

You need to use {'Color'} in the onCleanup object's function because that uses the "set(H,NameArray,ValueArray)" syntax for the set function, while set(h, 'Color', 'r') uses the "set(H,Name,Value)" syntax. You could use {'Color'} in the get call as well, but it's not necessary in this case because you're only asking for one property.

[Wouter Van Werveke]

That's a nice idea, I didn't know about onCleanup objects and I also don't think I ever encountered the set(H,NameArray,ValueArray) before. Good to learn, thank you! I will accept the answer from Walter Roberson as it most accurately answers my question in its original form, stripped of a lot of context. But I will be implementing your solution to the problem with more information about the specific context.

[Walter Roberson]

You can save the handles that you got back from findObj somewhere, so that you could be sure of getting the exact handles back.

However... since you are setting all of the uicontrol except perhaps one button, then you do not care about order. Just set them all to disable, then set the one button to enable; to restore, set them all to enable (it won't matter that the one button was already set to enable.)

[Wouter Van Werveke]

Having looked back at my code, I've found that I had already implemented it this way. Except that I do, in fact, care about the order because not all uicontrols are necessarily enabled when the calculation starts and I want to make sure I don't enable anything that wasn't enabled before. Saving the handles from findobj at the start of the callback function then does indeed allow me to simply restore the original states at the end of the callback, when the lengthy calculation is finished.

However, there is another uicontrol (a checkbox) in my GUI which disables all uicontrols indefinitely, i.e. until the box is unchecked (don't ask me why). I (perhaps unwarrantedly) dislike storing all the uicontrol handles and their original states in the guidata of my GUI every time this checkbox is (un)checked. My current solution here is to store the object handles and original states in the UserData of the checkbox, which perhaps you might argue isn't much cleaner than storing them in the guidata. The onCleanup solution means I don't have to explicitly store this data anywhere, but I do have to create a field in the guidata to store the cleanup object, which I'm wondering how to weigh up against my current solution. I have to admit I am a little uncomfortable with writing something like

delete(handles.revertStates)

If I'm not mistaken, this means I am constantly creating and deleting this field when the checkbox is being checked and unchecked, or am I wrong about this? Not to mention that there could be references to a deleted field in other parts of the code (although there really shouldn't be - not at the moment at least). I'd be very interested to get your input on this!

Answer 2

[Jogesh Kumar Mukala]

Hi,

If no graphics objects are added to or removed from a figure, the findobj always generates the list in the same order. The findobj always returns all the objects in a hierarchical manner.

By observing the example you provided, it seems you have a doubt about the order of the list after applying some function over graphics objects. To clarify regarding applying some functions over graphics objects, you may refer below attached code. You can refer isa to understand the function in the code.

plot(rand(5))
h = findobj;
% Generates the list before applying the function
h
for i =1:length(h)
    foo(h(i));
end
% Generates the list after applying the function
k= findobj;
k


function foo(x);
if(isa(x, 'matlab.ui.Root'))
% Change the units of graphic object root as it doesnot have color property 
    x.Units = 'pixels';
elseif(isa(x,'matlab.graphics.chart.primitive.Line'))
% Change color of the graphic objects lines
    x.Color = [1 1 0];
else
% Change color of the graphic object figure
    x.Color = [1 1 1];
end
end

[Walter Roberson]

fig = figure(1);
ax1 = axes(fig, 'tag', 'ax1');
ax2 = axes(fig, 'tag', 'ax2');
findobj(fig)

ans = 
  3×1 graphics array:

  Figure    (1)
  Axes      (ax2)
  Axes      (ax1)

uistack(ax1,'top')

drawnow()
findobj(fig)

ans = 
  3×1 graphics array:

  Figure    (1)
  Axes      (ax1)
  Axes      (ax2)

This example proves that uistack() can affect the order in which findobj() retrieves objects.

[Jogesh Kumar Mukala]

Thanks for pointing it out Walter.