Is there any way to get the uigetfile panel to be centered in the monitor when it first comes up????

I use the MATLAB function uigetfile to read in the path and name of a file. How do I get that panel to appear in the center of the screen. It always pops up in the upper left corner of the screen.

Note, this code must work with the compiler also.

Thanks Bob

[Robert Garneau]

MATLAB Technical Support also said there is no way to solve this issue even in MATLAB 2021b update 3.

Because my customer requested these panels to be centered on several occasions, I figured out a work around that appears to work.

I wrote a little function that I call that creates a figure on top of all of my larger figures/plots just before I call the the MATLAB "uigetfile" or "uiputfile" functions:

% this is the function I call from my application code....
function [fig] = makeFileFig()
% Need a little figure to fix it so the uigetfile/uiputfile 
% panels appears in the center of the monitor's screen rather than
% always appearing in the upper left hand corner where they always appear.

% My work-around seems to work.  But I need to continue testing
% It worked in several places but I want to continue implementing it
% and testing it. 

fig=figure();
fig.NumberTitle = 'off';
fig.Name = '';
fig.Units = 'normalized';
fig.Visible = 'on';
fig.WindowStyle = 'modal';
fig.Position =[0.3 0.3 0.473 .5];
fig.Color = 'w'; 

% The CenterFigure function call I have here uses  groot to get the screen size and then I center the figure.
CenterFigure(fig);
end



% inside my application code I have the following call to the above function:
fig = makeFileFig();

%  I then use any normal call to uigetfile or uiputfile..... which is NOW Centered on my Monitor Screen....
[ filename pathname] = uigetfile(........see MATLAB docs for property pairs ...);
    % At this point I have the file name and pathname from the uigetfile call...
% next, I delete the figure 
delete(fig);

This seems to work fine so far, because the “uigetfile” fuction always sticks its panel in the upper left corner of its figure. Because the little figure window, ( just a touch bigger than the uigetfile panel is centered), uigetfile panel looks centered.

So far it has worked in several places but I’ll know for sure when I embed it into all of my code. My app is quite large and I use “uigetfile” and “uiputfile” hundreds of times so it will take a while to update my system with the changes, I plan on making this change a little at a time as I add other functionality.

Bob

It works for me and that is all I care about. See attached figure.

[Matt J]

That doesn't work for me. I don't see why it would work either. The uigetfile window has nothing to do with the position of other figures.

[Walter Roberson]

In my test on MacOS, the position of the uigetfile window was consistent in absolute coordinates, and was not affected by the positions of any of my other windows. It also was not affected by dragging the position of the selection window in previous runs. Furthermore it did not match anything about get(groot, 'DefaultFigurePosition')

[Robert Garneau]

I am sorry Walter, I guess I did not make it clear that the "CenterFigure" function was one of my own that is passed in a handle to a figure or panel and centers it on the current computer monitor. I believe it works fairly well. I have only had issues with it a couple of times.

See the m file attached. It is the "CenterFigure" function that I used above.

[Walter Roberson]

@Robert Garneau

It does not matter.

The central thesis of using that code is that uigetfile() brings up a window that is centered on the current figure, so you create a centered figure for uigetfile() to appear over and so be centered itself.

However, for MacOS at least, the position that uigetfile() opens at is unrelated to the position any existing figure.

You are, at best, seeing operating-system dependent behaviour.

[Robert Garneau]

My customers only use Windows. Operating-system dependent behavior is fine with me if it solves an appearance issue that bothers my customers that no one else seems to have a solution for. If I have to do tricks to work around a defect in MATLAB or anywhere else, I will do it to keep my customers happy. Technical support says they will submit the issue to MATLAB developers to possible allow future versions of the uigetfile() and uiputfile() functions to be centered on the window. (They suggested I use a ListBox in the mean time. But List Boxes are not as pleasing or functional as the uigetfile() and uiputfile() MATLAB functions)

My "tricks" work for now and eventually when they fix the issue in "some future" version of MATLAB, I will remove the "TWO" lines of code that I have to wrap around uigetfile() and uiputfile() in each of the modules where they are used. So for now, "Operating-System Dependent Behavior" is best for me. It works.

[Walter Roberson]

@Robert Garneau

Having the functionality work sometime is better than not having it work at all.

However, as you are working with Windows, do not be astonished if it suddenly stops working with some KB*, or if it works differently depending which Creators Edition or half-year Windows update, or whatever.

[Matt J]

So for now, "Operating-System Dependent Behavior" is best for me. It works.

I'm on a Windows 10 OS and, as I said, the method doesn't work on my machine. I think you will see that if you manually drag the uigetfile window to some random location on the screen and then re-run your code. In Windows, the uigetfile windows will always open where it was last positioned.

Answer 1

[Walter Roberson]

No, there is no control over that.

If you are not using a deployed app, then MATLAB runs a java method to start an operating-system native file picker. There are no user-level controls over where that operating-system facility will appear.

Answer 2

[Matt J]

If you drag the uigetfile window to the location where you want it then, the next time you call uigetfile, it will open in that position, even if it's in a later Matlab session. I don't know if something similar would hold true for a deployed app.

[Walter Roberson]

This does not work for me in MacOS.