In R2024b, handles(33) throws an error. In R2023b in returns a structure if there is a figure 33. Is there a workaround in R2024b?

We have code that checks to see if a figure exists. That code works in R2023b and R2025b, but not in R2024b.

In R2024b:

>> isempty(fields(handle(33)))
Error using handle
Cannot convert to handle.

in R2023b:

>> isempty(fields(handle(33)))
ans =
logical
1

Is there a workaround in R2024b?

Answer 1

[dpb]

figExists=@(n)~isempty(findobj('Type','Figure','Number',n));

should work no matter the version.

Nota Bene: all these work only for classical figures; the uifigure doesn't have a number as the hidden 'IntergerHandleI' property is 'off', not 'on'

figExists(33)

ans = logical
   0

figure(33)
figExists(33)

ans = logical
   1

[Walter Roberson]

If you use

fig = uifigure(IntegerHandle=true, Number=33)

then the uifigure() that you get back does have its Number property set to 33. However, double(fig) shows that the assigned handle number will be increasing integers starting from 1.

[dpb]

Yeah, there's always going to be discrepancies possible with the dichotomy of having the two similar but not alike figure types. So far, the only way I've found that one can distinguish via properties(*) is that by default the number and integer handle are empty and off, but if one obfuscates on purpose as above all bets are off.

The only sure-fire way I've figured out so far is to try to use one of the controls that can only be hosted by the uifigure and catch the error if it fails for a target figure.

[Walter Roberson]

You need to use findall() instead of findobj() to take into account that HandleVisibility defaults to off for uifigure()

[Walter Roberson]

uifigure() have the property isUIFigure but regular figures do not have that property.

Answer 2

[Walter Roberson]

try
   figExists = isempty(fields(handle(33)));
catch ME
    figExists = false;
end

It turns out that uifigure() can have an associated number, if they are created by

fig = uifigure(IntegerHandle=true, Number=33)

This will assign an object with an integer handle to fig, and the Number associated with the uifigure will be 33 (in this case)

However! The value of double(fig) (the integer associated with the handle) will be an increasing integer starting from 1, which will not typically happen to be 33. For example it might assign handle(1) or handle(2) to fig.

In R2024b, although it is an error to try handle(33) if 33 does not happen to be associated with any handle, it is not an error to try handle(33) if there happens to be a figure or uifigure associated with 33. So for R2024b (only), you could use

try
    handle(33);
    figExists = true;
catch ME
   figExists = false; 
end

again, subject to the provision that it happened to associate 33 with the figure handle, not the case that the Number property of the uifigure was 33.

For the case of number property,

figExists=@(n)~isempty(findall(groot,'Type','Figure','Number',n));

findall(groot) is needed instead of findobj() because uifigure() defaults to HandleVisibility 'off', so by default uifigure handles are not findable by findobj()

[Dick Curran]

Although the answer works, noone has commented as to why my original formula works for R2023b and R2025b but not for R2024b. Any idea why that is?

[Walter Roberson]

We aren't Mathworks, we can't always explain what it does.

[dpb]

>> hUIF=uifigure;
>> hUIF.isUIFigure
Unrecognized method, property, or field 'isUIFigure' for class 'matlab.ui.Figure'. 
>> 

That's a new introduction after the lastest release I've installed...however, the error message reminded me of what I've overlooked to date--

>> class(hUIF)
ans =
    'matlab.ui.Figure'
>> hF=figure;
>> class(hF)
ans =
    'matlab.ui.Figure'
>

[dpb]

which -all handle

built-in (/MATLAB/toolbox/matlab/lang/handle)

@Dick Curran -- Since handle is builtin I think only Mathworks could tell you what was different in that particular release. I presume it probably would have been considered a bug if had been reported.