uigetfile() goes behind main figure

Hi,

uigetfile(), I think, creates a new figure; it has no parent argument. A number of people complained that its dialog window has unexpeced bahaviour in terms of appearance and focus.

I'm calling it from my main figure (created programmatically with uifigure). The uigetfile() dialog opens as a child of MATLAB window, and NOT as a child of my GUI app which is actually calling it. I.e. it opens behind the main app (problem #1); you need to click on Matlab icon to see this dialog, then, once you select file(s) the focus remains with Matlab window, then, to come back to your app (problem #2), again, manually click on your app to give it the focus.

I found one workaround which seems failing in 2021b on Mac--the dialog still opens behind the main calling app:

f2 = figure('Visible','off'); % create a dummy figure
drawnow; % give it a focus
[file, path] = uigetfile(...); % call this stubborn thing
delete(f2);  % delete dummy
% the above does not work on Mac

% then the 2nd workaround, to give focus back to the calling main fig
% it works fine
drawnow;
figure(f); % f is a handle of the main fig, created with uifigure()

Anybody can help to open this dialog on top of the main app?

I'm on MacOS Monterey. It could be OS dependant, I'm afraid.

The thing is: the new figure is spawned inside uigetfile(), and currently uigetfile() has no way to explicitly mention the parent, therefore, I believe it is Java/OS who decides on the ancestor. And at least on Mac it decides to open it in the main Matlab window. Maybe the dummy figure workaround works on Win (or there is no problem #1 on Win in the first place). One can work with Java window manager to change the focus, but this needs to be done right after the appearance of the dialog, i.e. inside the uigetfile(), not before or after its call.

Eventually, I want to compile the app to a standalone. Thus, there will be no Matlab main window. Maybe then it will behave better. What I'm hearing from others is that this appearance/focus behavior is not consitent between App-Design-created vs programmatical, compiled vs in-Matlab, and diff versions.

Thanks

Answer 1

[Pierre]

Alright, so it looks like, at least with the version I'm running as of writing (R2022b), the only available solution is a brute force approach similar to that suggested for other, slightly different problems involving uigetfile() and uifigure focus. The idea is to hide your main UI window (and any other windows that the uigetfile dialog might be hiding behind), then call uigetfile(), and then make your windows visible again (h/t @Chris McRaven and others):

app.UIFigure.Visible = 'off'; % Hide the main window
[file, path] = uigetfile(); % Trigger the uigetfile dialog
app.UIFigure.Visible = 'on'; % Make the main window visible again

The main difference with the solutions to the question linked by @Prathamesh Kulkarni is that here we really need to hide the main window before calling uigetfile() since we're not just doing the Visible 'off'/'on' trick to force Matlab to snap focus back to the main window. And if your app has opened other sub-windows that the uigetfile dialog might also be hiding behind, you'll have to manually hide them as well before calling uigetfile().

I really wish there was a nicer way to do this (or simply that dialog windows auto-focused) but what can you do.

[Valtar]

Salut Pierre,

Thanks for looking into this.

My app is done programmaticaly, not in appdesigner. But I think it does not matter.

Then, I don't see any trouble in Matlab on Win or for the compiled app for Win (and run it in Win). The problem for me exists only in Matlab on MacOS (and I don't need to compile it for mac, thus I don't know its behaviour for compiled version on mac). To summarize: no issue on Win, the problem is only in Matlab on Mac. I'm using 2022b on both Win and Mac.

Your solution ( very clear explanation; chapeau!) does solve my problem on mac:

f = uifigure(); % main figure
...
if ismac, f.Visible = 'off'; end % workaround only for mac
[file, path] = uigetfile();
if ismac, f.Visible = 'on'; end % workaround only for mac

The workround above I only need for Matlab on Mac. In Matlab on Win I don't have this problem.

However, in the compiled version on the same app on Win I see that after the diagolgue, the focus is switched to... File Explorer (where I started the app from)... funny... and to return the focus back i need this:

drawnow;
figure(f);

For the compiled version on Win, probably, your workflow with hiding/showing the main window would work as well, however, i don't want to hide the main window in general (it looks confusing in a way). So, on mac I need it, but for Win hiding it not needed, beucase the dialogue appear on top of the main window.

Merci bcp!

[Pierre]

Yeah I'm not actually using appdesigner either, I'm developing a UI frontend that plugs onto a larger object-based backend — I just figured I'd re-use the appdesigner-based example for clarity. I haven't tested my app on Windows so I can't comment on the OS differences but I'm glad the workaround solved your problem on Mac!

[Andy Perrin]

val and Pierre, just had this problem in R2023a and it's amazing that this is still an issue in 2023!!

Mathworks, get on the ball here!

Answer 2

[Prathamesh Kulkarni]

Hi Val,

I don't think it's an OS specific issue. Similar questions were asked earlier, you can refer to the answers provided to the following question. I hope it will resolve your issue.

https://in.mathworks.com/matlabcentral/answers/296305-appdesigner-window-ends-up-in-background-after-uigetfile?s_tid=answers_rc1-3_p3_Topic

[Pierre]

I'm having the exact same issue as OP, in which the uigetfile() dialog itself ends up behind the main uifigure, whereas the question you linked to involves the main figure somehow being sent to the background after calling uigetfile(). Similar questions, but different problem.

Still doing my research on the question, I'll report back if I find anything.

[Eric Delgado]

The issue remains in R2024a when using MacBook. :(

Please, @MathWorks Support Team, add this issue to developers backlog.