As of R2025ab, are all figures now uifigures?

Prior to R2025, the result of the code below was tf=0. Have the figure and uifigure frameworks been unified somehow? Is that why tf is now 1?

fig=figure; plot(1:5);

tf = matlab.ui.internal.isUIFigure(fig)

ans = logical
   1

[dpb]

hF=figure

hF = 
  Figure (1) with properties:

      Number: 1
        Name: ''
       Color: [1 1 1]
    Position: [1628 1512 560 419.7599]
       Units: 'pixels'

  Use GET to show all properties

That looks like a regular figure given that it has a number; for uifigures the .Number property has always been empty.

What does

hUF=uifigure

return?

By default, the .IntegerHandle' property is 'on' for regular figures and 'off'' for UIFigures. As well 'HandleVisibility' is the same set of default properties so gca won't find a UIFigure, but will create a regular figure if one doesn't exist.

[dpb]

What happens with

fig=figure;
hBtn=uibutton(fig);

? If it's a regular figure, this will fail.

Answer 1

[dpb]

This appears to be a result of the replacement of Java for rendering...

which -all matlab.ui.internal.isUIFigure

/MATLAB/toolbox/matlab/uitools/uitools/+matlab/+ui/+internal/isUIFigure.m  % static method or namespace function

fn=which('matlab.ui.internal.isUIFigure');
type(fn)

function bool = isUIFigure(f)
%isUIFigure checks if the given figure is a java or web figure using 
% JavaFrame property.
% f is figure handle
% bool is output boolean value

% Copyright 2017 The MathWorks, Inc.

% if JavaFrame is empty, then this is a web figure.
if ~isempty(f) && isempty(get(f,'JavaFrame_I'))
    bool = true;
else
    bool = false;
end
end

hF=figure;
hF.JavaFrame_I

ans =

     []

hUF=figure;
hUF.JavaFrame_I

ans =

     []

By comparison, with release prior to R2025, the results are:

>> hF.JavaFrame_I
ans =
com.mathworks.hg.peer.HG2FigurePeer@f14e5bf
>> hUF.JavaFrame_I
ans =
     []
>>

Now whether this is an oversight on Mathworks' part in not making a change here or not I don't know, but it does seem like a reasonable query.

[Matt J]

I guess that's got to be it.

[dpb]

I don't know there's sufficient public information that users can know precisely what Mathworks' long range intentions are regarding the dual nature of now having two types of figures. Given that, I would think this would be worthy of submiting as a potential bug or at least an interpretation and how one is supposed to be able to know to avoid things such as the suggested test by trying an expected failing operation.

[Matt J]

Since matlab.ui.internal.isUIFigure is undocumented, I think they'll just tell me it was never intended for public use.

[dpb]

If couched that way, perhaps. I was thinking if there were a use case where you were using this and not just poking around to see what could find, asking for method to determine which would not be inappropriate since this doesn't return anything useful for purpose now. But, as you note, they've always got the backdoor exit if choose to use it...

[Matt J]

One thing that might be worth pointing out: my original need for matlab.ui.internal.isUIFigure seems to have disappeared in R2025. Originally (pre-R2025) appdesigner apps would break when setting,

 set(groot,'defaultFigureCreateFcn',@(fig, ~)addToolbarExplorationButtons(fig));

when fig was a uifigure, so I used matlab.ui.internal.isUIFigure to do so selectively:

 set(groot,'defaultFigureCreateFcn',@(fig, ~)addFigButtons(fig));
 
 function addFigButtons(fig)

  if ~matlab.ui.internal.isUIFigure(fig)
     addToolbarExplorationButtons(fig)
  end


end

But now, that conflict seems to be gone!

[dpb]

Interesting. With so much revision in the desktop and that I have a quite slow connection I've not yet installed R2025x.

I guess then this case would resolve to test a version if you have to support anything other than latest.

I haven't tried it, but I was thinking it might be interesting to grep the string 'isUIFigure' and see just where (in visible code at least) it might be being used and for what kind of branching, maybe.

I've been since the initial introduction and am still curious about what the really longterm intent is with having the two--will the venrable figure eventually morph into the other and simply become redundant syntax for the same thing, maybe?