I'm trying to use the wait bar in a gui for a matlab program that recognises images. In simple words, a bounding box(rectangle) appears when there is a irregularity.
The bounding box doesnt appear when I have the waitbar as normal or modal:
f = waitbar(0,'Please wait...','WindowStyle','normal');
But the bounding box appears when I use the following command
f = waitbar(0,'Please wait...','WindowStyle','docked');
I would want the wait bar to pop and not be docked. Any suggestions?
Recommendations?
Thanks
#ssroy, The bounding box(rectangle) is probably added to the figure of the waitbar instead of the figure where you want it. I would try to recall focus to that figure (or your GUI) when adding the bounding box, and follow it by refocussing on the waitbar afterwards.
In order to refocus on the waitbar , you can use again f = waitbar(0,'Please wait...','WindowStyle','normal'); even if you don't change anything on it
Related
I am having a GUI figure, which contains some buttons, I want to show waitbar on the same GUI window on which buttons are placed, I tried different solutions but in vain. e.g when user clicks on button it starts showing me waitbar on left bottom side of the figure.
You could try to add a java waitbar in your figure.
Put this in the OpeningFcn
PB=javaObjectEDT(javax.swing.JProgressBar);
javacomponent(PB,[10,10,200,20],gcf); %put at bottom part of the current figure
set(handles.output.Children(1),'Tag','first_bar'); %make sure you can find it back
In the callback of any function you can then set the bar to a value between 0 and 100 using this code:
h=findobj(handles.output.Children,'Tag','first_bar');
set(h.JavaPeer,'Value',rand(1)*100)
You can make it visible or invisible just as you would any GUI object in Matlab using
h=findobj(handles.output.Children,'Tag','first_bar');
set(h,'visible','off');
Here you can find details about the JProgressBar . For example using this you get a string with the progress inside the bar.
h=findobj(handles.output.Children,'Tag','first_bar');
set(h.JavaPeer,'StringPainted',1)
I used Matlab GUIDE to create a GUI.
It is displayed mid-screen.
How can I position it at the top of the screen; so that the top edge of the GUI window is at top of screen.
It will be used on different Windows 7 computers with different screen resolutions.
I tried to set hObject.Position(2) but it doesn't do what I want.
I think the simplest way would be to use movegui in the OpeningFcn of your GUI with the appropriate argument, i.e. using either 'north', 'northeast' or 'northwest'.
The calling syntax is quite simple, using the handles to the figure created. In GUIDE, the default name for figures is "figure1", so in your case the code would look like this (unless you changed the figure's name):
movegui(handles.figure1,'northwest') %// or whatever
Note that movegui calls the following 3 functions to get the screen size and monitor positions/units:
screensize = get(0, 'ScreenSize');
monitors = get(0,'MonitorPositions');
old0units = get(0, 'Units');
So you could do the same to make the calculations yourself in order to place the figure precisely where you want if the above solution is not sufficient for you.
When Matlab is processing code including the plot() command, Matlab will steal window focus, when plot() is processed. While many seem to find this behavior annoying, I find it useful as an alert telling me when the plot has been processed, and I can do something else while Matlab is running.
I would, however, like to have Matlab stealing window focus whenever calculations are done (Matlab being idle), and not just when I include the plot() or figure() command.
I have found a post about disabling the window stealing behavior of plot() and figure() (Inhibit Matlab Window Focus Stealing), but not on adding window stealing behavior when calculations are done. Can it be done?
To make Matlab command window get focus, you can add commandwindow after the calculations. From the documentation,
commandwindow opens the MATLAB® Command Window when it is closed, and selects the Command Window when it is open.
To make an existing figure get focus, you can add figure(h), where h is the figure handle. From the documentation,
figure(h) does one of the following [...]
If h is the handle or the Number property value of an existing figure, then figure(h) makes that existing figure the current figure, makes it visible, and moves it on top of all other figures on the screen. The current figure is the target for graphics output.
I know that one can insert a colorbar by clicking the colorbar icon in the clustergram GUI. Is there a way to do it programmatically?
I tried
cgo = clustergram(data)
colorbar;
This makes a colorbar in a new figure window. How can a colorbar be created with proper positioning in a clustergram figure as if the button was clicked?
There is a function buried away (HeatMap.plot>showColorbar) that neatly positions the colorbar to the left of both the heat map and the dendogram (the lines). Just running colorbar(...) will mess up the relative positioning of the dendogram and the heatmap. So you need to somehow run the callback or carefully duplicate all of the position computations. It's easier to just run the callback. Here's how.
To create the colorbar programmatically for a clustergram, and keep the color bar button in sync, you need to use the button's assigned callback and set the button's state.
Create the clustergram:
load filteredyeastdata
cgo = clustergram(yeastvalues(1:30,:),'Standardize','Row');
Get the handle for color bar button:
cbButton = findall(gcf,'tag','HMInsertColorbar');
Get callback (ClickedCallback) for the button:
ccb = get(cbButton,'ClickedCallback')
ccb =
#insertColorbarCB
[1x1 clustergram]
That gives us a handle to the function assigned by the callback (#insertColorbarCB), and the function's third input argument (the clustergram object). The button's handle and an empty event object are implicitly the first two arguments.
Change the button state to 'on' (clicked down):
set(cbButton,'State','on')
Run the callback to create the colorbar:
ccb{1}(cbButton,[],ccb{2})
Note that the button State must be changed to 'on' first, otherwise the callback won't do anything.
I just managed to solve this problem.
What I did:
I added this function to the clustergram code (I put it at line 1486)
%%%%%%%%%%%%%%
function insertColorbarCBALWAYS(obj)
hFig= gcbf;
obj.Colorbar = true;
end
%%%%%%%%%%%%%%%
and then at line 415 of the clustergram.m file I added this line of code
insertColorbarCBALWAYS(obj);
to call the above function. Save and go: now the colorbar will always be there, once the clustergram is drawn.
Previous method was not working for me so I made this workaround.
One may even save the new clustergram code as clustergramCM such that you can draw cgram in both ways.
I've writtend a GUI function in MATLAB R2009b which makes use of the IMRECT function. I need to make sure this GUI also works in MATLAB R2007b: since this release the IMRECT function has undergone extensive changes. I have two question:
1 - in the new (R2009b) IMRECT, a method GETCOLOR is defined which allows to get the color which was selected by the user using the scroll menu. Is there a way to mimic this behavior for the old (R2007b) function?
2 - in MATLAB R2009b I can use WAIT after using IMRECT as follows:
h = imrect(axhandle);
wait(h);
this allows to wait unitl the user as correctly placed his/her rectangle and has double click to confirm the choice. Is there anything analogous that can be used with IMRECT from R2007b?
Unfortunately, you need a workaround for both functions.
Here is one way to do it:
%# Create a figure and some points
fh = figure;plot(rand(10,1),rand(10,1),'.')
ah = gca;
%# this allows the user to place the rectangle. However, the code resumes
%# as soon as the rectangle has been drawn
rh = imrect(ah,[]);
%# Create a dialog to have the possibility to uiwait
wh = warndlg('Please close this dialog once you are done adjusting your rectangle');
uiwait(wh)
%# Get the color of the rectangle
rectKids = get(rh,'Children');
rectangleColor = get(rectKids(1),'Color');
You can use verLessThan to check for the Matlab version in order to get the proper functionality. However, if there are users who'll use the code both on 2007b and 2009b, I suggest you leave the dialog box in for everyone, so that they don't get confused when they switch.