Stupid, simple question - is the value of gcf in matlab always going to be the figure number of the active figure? I.e., if I'm working on Figure 5, will gcf always return 5?
GCF returns the handle of the "current figure". This is always the figure number of the active figure. However, if you click on a different figure in the meantime, that other figure will become active. Thus, if you already know what figure you're working with, because you either forced the handle to 5 by calling figure(5), or because you captured the handle in a variable by calling fh=figure; it is safer that you use the handle instead of gcf whenever you want to modify the figure to avoid risking to inadvertently making another figure active.
Also, if there is no figure currently open, gcf will open a new figure.
This is a little more complicated than a simple "yes" or "no" answer. The handle for the current figure will generally match the number displayed at the top left of the figure window, but this number is only displayed when the 'NumberTitle' figure property is set to 'on' (the default).
Another wrinkle is that the figure handle is not guaranteed to be an integer. There is an 'IntegerHandle' figure property which determines if the handle created for the figure is an integer or a non-reusable real number. If this property is set to 'off', you get handle values that aren't integers, so the first figure that you open won't have a handle of 1. For example:
>> hFigure = figure('IntegerHandle','off') %# The only window open
hFigure =
173.0040
And the figure is numbered accordingly:
Notice that when the figure number and handle are displayed, there is some round-off of the number. The figure window only displays 6 digits past the decimal place. It becomes apparent that you're dealing with floating point numbers when you change the format of the Command Window to show more decimal places:
>> format long
>> hFigure
hFigure =
1.730040283203125e+002
In this case, the displayed figure number and the figure handle differ slightly.
Yes, gcf will return the handle of the currently selected (or active) figure. From the documentation,
H = GCF returns the handle of the current figure. The current
figure is the window into which graphics commands like PLOT,
TITLE, SURF, etc. will draw.
But also remember that:
The current figure is not necessarily the frontmost figure on
the screen.
One way to make a figure "current" is:
Clicking on uimenus and uicontrols contained within a figure,
or clicking on the drawing area of a figure cause that
figure to become current.
Another way is to use the figure handle. i.e., if you called the figure as h=figure;, then figure(h) will make it the current figure.
Related
As the title states, I need to get a handle for my Matlab application. My class is derived from matlab.apps.AppBase and is app.UIFigure (if that matter, I'm still learning Matlab). My main goal is to change the mouse cursor to watch after a button is clicked and data is processed in the background.
I have tried:
set(gcf,'Pointer','watch')
But gcf is just empty, so it creates a new figure. I have also gotten all of the figures, using:
figs = findall(groot,'Type','Figure')
Which finds all of the figures I am using. I believe that I need to get the overall application figure and find the handle, but I am unsure how to do that.
There is no pointer property for uifigure; otherwise, you would be able to use app.UIFigure.Pointer = 'watch' as suggested by #CrisLuengo.
However, specially for uifigure MATLAB provides a nice looking and powerful progress bar uiprogressdlg. You can make it indeterminate with uiprogressdlg.Indeterminate = on;. I find this working pleasingly well.
Here is an example:
f=uifigure;
progressdlg=uiprogressdlg(f,'Title','Progress','Message', 'Doing something please wait', 'Indeterminate','on');
pause(10); % Run your algorithm.
% Delete the progress bar after work done.
progressdlg.delete();
How is it possible to find out which control in a given MATLAB GUI is currently selected by the user?
For example I want to find out which edit box in the GUI is currently focused since I want to exploit the figures WindowScrollWheelFcn to allow increasing/decreasing numeric values by scrolling up/down while the relevant input is selected.
Let f be a handle to the GUI figure. Then
h = get(f, 'CurrentObject')
returns a handle h to that figure's current object, which is the one most recently selected in that figure (see the documentation of figure properties for more information).
(Note that gco returns the current object in the current figure. This is not what you want, because the user may have clicked an object in another figure).
I've a GUI(i.e. lets call it 'First')through which i can choose to open other GUIs(let's call them 'Second' and 'Third').I want to put a 'pushbutton' on the 'First'GUI that allows me to manipulate the figure on the different axes of the 'Second' and 'Third' GUIs. So, i choose with the 'First'GUI if use either 'Second' or 'Third' GUI; once i've chosen that i start to work just with the GUI that i chose (so the Third one or Second ones). Now i want to have a pushbutton not on each GUIs (Second or Third) but only on the First one in order to manipulate the figure on the axes 1 of the Second or Third (depends on which one i've previously chosen). Furthermore this pushbutton that i want is optional and i need to refresh my axes after used that.
I've done my best to explain the situation,please if you know any solution help me out!!Thanks
Your question is similar to other examples, such as this.
To understand how to solve your problem, you need to remember that MATLAB "decides" which axes to update based on the axes handle provided by the user. If the user doesn't provide a handle, a default gca (the current axes) is used. The axes that gca points to, is the first child of type 'axes' of the figure, that is, the first entry in findobj(hFigure,'Type','axes'). You can read about setting the current axes here.
Having established that, the solution you are looking for would involve storing the axes handles somewhere, and retrieving the correct one when you are about to update a plot. A common place to store it is the "application-defined data" (appdata), accessible by setappdata and getappdata, as mentioned in the first link above and also here.
The procedure you should undergo is:
Upon creating a figure, store the axes handle in appdata by calling setappdata(0,name,val) (e.g. setappdata(0,'axTag1',handles.axTag1)) from your GUI initialization function. The value 0 for the 1st argument stores it in MATLAB's root object (you can think of it as the main MATLAB window), so that even if any of the figures is closed, the information is maintained as long as MATLAB is still open.
Whenever you want to modify an axes, just obtain the appropriate handle using value = getappdata(0,name) and use it to update the corresponding axes.
In Matlab, I would like to update the data plotted in a set of axes when the user zooms into the plot window. For example, suppose I want to plot a particular function that is defined analytically. I would like to update the plot window with additional data when the user zooms into the traces, so that they can examine the function with arbitrary resolution.
Does Matlab provide hooks to update the data when the view changes? (Or simply when it is redrawn?)
While I have yet to find one generic "redraw" callback to solve this question, I have managed to cobble together a group of four callbacks* that seem to achieve this goal in (almost?) all situations. For a given axes object ax = gca(),
1. Setup the zoom callback function as directed by #Jonas:
set(zoom(ax),'ActionPostCallback',#(x,y) myCallbackFcn(ax));
2. Setup a pan callback function:
set(pan(ax),'ActionPostCallback',#(x,y) myCallbackFcn(ax));
3. Setup a figure resize callback function:
set(getParentFigure(ax),'ResizeFcn',#(x,y) myCallbackFcn(ax));
4. Edit: this one no longer works in R2014b, but is only needed if you add, e.g., a colorbar to the figure (which changes the axis position without changing the figure size or axis zoom/pan). I've not looked for a replacement. Finally, setup an undocumented property listener for the axes position property itself. There is one important trick here: We must hold onto the handle to the handle.listener object as once it's deleted (or leaves scope), it removes the callback. The UserData property of the axes object itself is a nice place to stash it in many cases.
hax = handle(ax);
hprop = findprop(hax,'Position');
h = handle.listener(hax,hprop,'PropertyPostSet',#(x,y) myCallbackFcn(ax));
set(ax,'UserData',h);
In all these cases I've chosen to discard the default callback event arguments and instead capture the axis in question within an anonymous function. I've found this to be much more useful than trying to cope with all the different forms of arguments that propagate through these disparate callback scenarios.
*Also, with so many different callback sources flying around, I find it invaluable to have a recursion check at the beginning of myCallbackFcn to ensure that I don't end up in an infinite loop.
Yes, it does. The ZOOM mode object has the following callbacks:
ButtonDownFilter
ActionPreCallback
ActionPostCallback
The latter two are executed either just before or just after the zoom function. You could set your update function in ActionPostCallback, where you'd update the plot according to the new axes limits (the handle to the axes is passed as the second input argument to the callback).
I'm trying to annotate a polar plot with data tips labelled with 'R:...,Theta:...' where theta is actually the Greek symbol, rather than the word spelled out. I'm familiar with string formatting using '\theta' resulting in the symbol, but it doesn't work in this case. Is there a way to apply the LaTeX interpreter to data tips? Here's what I have so far:
f1=figure;
t=pi/4;
r=1;
polar(t,r,'.');
dcm_obj = datacursormode(f1);
set(dcm_obj,'UpdateFcn',#polarlabel)
info_struct = getCursorInfo(dcm_obj);
datacursormode on
where polarlabel is defined as follows:
function txt = polarlabel(empt,event_obj)
pos = get(event_obj,'Position');
x=pos(1);
y=pos(2);
[th,r]=cart2pol(x,y);
txt = {['R: ',num2str(r)],...
['\Theta: ',num2str(th*180/pi)]};
Update: This solution is primarily applicable to versions R2014a and older, since it appears to fail for newer versions, specifically R2014b and newer using the new handle graphics system. For newer versions using the new handle graphics system, a solution can be found here.
For some odd reason, the data cursor tool in MATLAB forcibly sets the data tip text to be displayed literally instead of with TeX/LaTeX interpreting (even if the default MATLAB settings say to do so). There also appears to be no way of directly setting text properties via the data cursor mode object properties.
However, I've figured out one workaround. If you add the following to the end of your polarlabel function, the text should display properly:
set(0,'ShowHiddenHandles','on'); % Show hidden handles
hText = findobj('Type','text','Tag','DataTipMarker'); % Find the data tip text
set(0,'ShowHiddenHandles','off'); % Hide handles again
set(hText,'Interpreter','tex'); % Change the interpreter
Explanation
Every graphics object created in the figure has to have a handle. Objects sometimes have their 'HandleVisibility' property set to 'off', so their handles won't show up in the list of child objects for their parent object, thus making them harder to find. One way around this is to set the 'ShowHiddenHandles' property of the root object to 'on'. This will then allow you to use findobj to find the handles of graphics objects with certain properties. (Note: You could also use findall and not worry about the 'ShowHiddenHandles' setting)
Turning on data cursor mode and clicking the plot creates an hggroup object, one child of which is the text object for the text that is displayed. The above code finds this text object and changes the 'Interpreter' property to 'tex' so that the theta symbol is correctly displayed.
Technically, the above code only has to be called once, not every time polarlabel is called. However, the text object doesn't exist until the first time you click on the plot to bring up the data tip (i.e. the first time polarlabel gets called), so the code has to go in the UpdateFcn for the data cursor mode object so that the first data tip displayed has the right text formatting.