Reprint from the Light dust
[Fig file mode, i.e. using menu File->new->gui to design the interface]
First of all, it is important to note that in the low version of Matlab, the M file containing the GUI cannot be run on the higher version of MATLAB. But it's been improved a little since version 7.0, I have tried the 6.5 version of the M file with the GUI can be run on version 7.0, but if you modified the. Fig file in version 7.0, then you can not go back to the 6.5 version of the run (show a bunch of errors, I did not understand, I do not know whether it can be modified to run on the 6.5 version, hehe), and in 7 The M-file with the GUI made on version 0 will not be able to run on version 6.5 (and the same error). This may be because the versions of MATLAB are larger on the GUI, so backwards compatibility is not supported. Perhaps poor compatibility is the biggest hassle of writing programs using the GUI.
Second, talk about the benefits of using the GUI. Do not know whether to inherit the habit of VC ORBCB, I prefer to write the program after the shortcut key to run (this will automatically save the M file), but, for the program has input parameters, if not the GUI way, this is obviously not feasible-of course, you can press the CommandWindow "up "Key and rewrite the parameters you want. For some of the larger programs, because I prefer to press F5 to run the program, so I will choose to use GUI mode. However, the advantages of GUI way is far more than this, it can be a few functional related modules together, so that do not need to shut down, run to get different results, easy to compare, can reduce the phenomenon of figure flying, which is particularly evident in MATLAB, it is very obvious in the simulation, easy to view the different data interactively, For example, in the fMRI problem I'm dealing with, I want to watch the time series corresponding to each three-dimensional point, which requires an interactive selection ... However, although the GUI has many advantages, but its shortcomings are also some, in addition to the above mentioned compatibility (portability), to manage and maintain a GUI interface is more troublesome, I believe that there are other language interface design experience of friends know this.
In addition, to the GUI problem, tell me a little experience of it. In fact, MATLAB has improved a lot in this area, from the increase in control and the learning of the tutorial can be seen. For example, the 6.5 version is not the panel and buttongroup the two controls, in the 2006a version of the two new controls (this seems to have 7.0 version, not sure); tutorial, also use the most intuitive video teaching method, suggest novice See Creatinga GUI With guide and creating graphical userinterfaces two sections. Therefore, the operation of the details I will not speak more, I feel it ok. As for the most critical parameter transfer problem in programming, you can refer to this forum or the simulation forum above the "function structure and parameter transfer" article, the author is more complete, but a bit difficult to understand. here, let me briefly say:
[Go cwit] About parameter passing method:
1. Extract in Memory:① is transmitted using function Varargin and varargout,② exists in the applicationdata of handle,③ is stored in handles. Of course there are other ways;
2. On the hard disk, use save and load;
3. Using global variables, most of the time, is sometimes the best approach;
I think, for the GUI problem handled here, generally do not use the Save and Load command (to read the data from the mat file initialization or the data stored in the Mat file exception), "function of Varargin and varargout transfer" method is not less used (because of the control's callback function, MATLAB specifies that the input parameter is "Hobject,eventdata, Handles,varargin", and generally no return value, so different from the custom function), so the remaining method is only three kinds of:
1. ApplicationData in the presence of handle--use the Setappdata function to save the data in the object's "ApplicationData" attribute, using the Getappdata function from the object's "ApplicationData" property to extract the data, or null if there is no definition. For example, assuming that the tag property of a figure is figure1, then Setappdata (Handles.figure1, ' a ', a) can store the variable a in the Figure1 "ApplicationData" attribute with the name A, and b= Getappdata (Handles.figure1, ' a ') can assign the variable named a in the "ApplicationData" attribute of Figure1 to B. Setappdata and Getappdata manipulate objects, preferably figure_handle, for ease of management and extension. MATLAB advanced programming and Object control, will be a large number of use of these two functions [transfer from cwit];
2. Save in handles-first, this is a common way to access the control, notice that tag is a property that uniquely identifies the control, and that if the tag property of a control is a, in the M file corresponding to fig, as long as the function containing "handles" as its input parameter , you can use HANDLES.A to access the control. Since the handle (equivalent to a pointer in other languages) has been taken, it is "slaughtered" (for example, setting properties, accessing data, etc.), and secondly, you can use this method to save the custom variables in handles for access, which in the MATLAB help Creatinga The GUI with the Guide section has the specific introduction, does not say much;
3. The method of using global variables-This is my common method of parameter passing, using the method is: in two function body (of course, it can be multiple, here is the main function and the meaning of the sub-function) before the use of the statement "Globala", where A is a plurality of functions need to pass the variable name, Multiple variables are opened with a blank, and no semicolon is required at the end of the sentence. This method can be slowed down because it is stored on the hard disk, but if the number of variables is not many, or the function of the variable is not many, consider this approach (I have not yet grasped the meaning of Cwit's "best method, sometimes the best approach").
for other GUI commands, control properties and graphics properties can refer to Matlab help, or refer to "GUI command Daquan", "Proficient GUI graphical interface Programming" (these two forums have), "Matlab Graphic image Properties", "Gui.rtf" (these two see accessories, The latter is manually modified after downloading the suffix name). In fact, more control properties are used than the following (Master exception):
Visible attributes, such as axes, edit, button, and so on, format: Set (handles.***, ' visible ', ' on '), or set (handles.***, ' visible ', ' off ');
String property, such as edit, text, etc., format: Str=get (handles.***, ' string ') or set (handles.***, ' string ', str);
The Enable property, such as Edit, button, text, and so on, format: Set (handles.***, ' Enable ', ' on '), or set (handles.***, ' Enable ', ' off ');
The Value property, such as radio button, checkbox, and so on, format: A=get (handles.***, ' value ') or set (handles.***, ' value ', 1), or set (handles.***, ' Value ', 0);
pay attention to the comment section of the response function, and sometimes you get a hint. For example, in my Matlab 2007a, after adding a ListBox control to the design interface, the corresponding callback function for M files appears as follows:
%---Executes on selectionchange in ListBox1.
Functionlistbox1_callback (Hobject, EventData, handles)
% Hobject handle to listbox1 (see GCBO)
% eventdata reserved-to bedefined in a future version of MATLAB
% handles structure withhandles and user data (see GUIDATA)
% hints:contents =get (hobject, ' String ') returns ListBox1 contents as cell array--This is a hint of the basic use of the control
%contents{get (hobject, ' Value ')} returns selected item from listbox1--This is a hint of the basic use of the control
Finally, I will introduce some of the problems or techniques I found in the process (really only a little bit, I hope I can continue to add the pull, these techniques for the M file way GUI also applies):
1. When the control position overlaps, the direct placement method is incompatible with the way the program is depicted. The direct placement method refers to the placement of the axes control in the GUI design window, which refers to the plotting of plot and subplot functions in the program. After I test, in the same fig file, first use the program to depict the graphics plot (at this time directly placed axes control is not visible), and then to the direct placement of the axes control to be re-set to the visible state, if the axes position controlled by the two ways overlap, The axes control handle that is placed is somehow gone and becomes an invalid handle, that is, invalidhandle error (although its handle is a value). Therefore, the position of the two methods can not overlap when they are used alternately. The root cause should be the 5th.
2. When there are multiple axes controls, you can use axes (handles.haxis) to select the switch, which is more flexible than plot (x, y, ' parent ', haxis) and should not be original (because it is introduced in the GUI-mastering book), But I have been using it until I read the book. Specifically, in the GUI of the fig file, assuming that your axes control has a value of HA for the Tag property, use Axes (handles.ha) before drawing, and you can specify that the axes be plotted on it; in the GUI of M file mode, suppose you are through ha=axes (... ); Create this control, then use Plot (x, y, ' parent ', HA), and the statement can be specified on the axes above the graph. Other controls are similar, with the edit control as an example, first add a Tag property to Edit1, namely: h_edit1= ... ' tag ', ' edit1 ' ...; And then use Set (Findobj (' Tag ', ' edit1 '), ' string ', ' 1234 '); Can.
3. Setting the Alpha (. 5) Statement of the object's transparency property affects the visibility settings of other objects, that is, when an object in the Fig window (my example is a Axes object) uses an Alpha statement to set its transparency, You cannot set the Visible property off for other objects in the Fig window, at which point the off value is invalidated, and the workaround is to set the Enable property on the other object to approximate the desired effect.
"Following transfer from Newseee"
4. Design Gui,mailab version of the higher the better, fewer bugs, full-featured. Like Uigeifile (or Uigetdir?) I can't remember. ) is not supported in R12. When initializing, add version judgment.
5.axes objects cannot be placed on top of other objects!
6.axes No callback, but you can put a picture (image), you can have callback.
7. Windows and Linux under the GUI will look different, in order to be compatible, the font changed to Default,unit units to use characters.
8. Dynamic graphics are drawn in loops. Open the figure's doublebuffer to on to avoid flicker. Remember to use Axes (h). Because once per plot, the coordinate system is refreshed. One cannot step into the same river.
9. Matlab R13 has bug,linux under submenu can not be updated dynamically, can be deleted, can not be added. My solution is to close the GUI in callback and then Update submenu (Function varargout = UNTITLED_OUTPUTFCN (Hobject, Eventdata,handles) in the main functions This line is added below, and the window has not yet been created. ), and then reopen the GUI.
[m file mode design interface]
This approach is best based on your own needs, download some specific examples as a reference (such as vibration or simulation of some of the cattle posted on the forum), combined with the task (or interest) to learn. Compared to the above fig file, this way can boast different MATLAB platform use, do not have to consider compatibility issues (of course, to meet a premise: to the platform's syntax or command support, such as && The 6.5 version is not valid, that is, if your program is written in 7.0 or more versions of MATLAB, but you want the program to run in version 6.5, you can only use & when writing conditional judgment statements, but the cost is the creation and layout of all controls, The event's response function entry, and so on, need to be implemented in code, so it is a bit more difficult than the fig file method. Of course, you can download other people's written interface to make changes. In general, if it is used for internal debugging, testing, the fig way is better, but if used to publish, or M file way more common point (although it can be packaged for a little more versatility, but you can't carry more than 100 m mcrinstaller files everywhere?) 2006B is more than 100 m,2006a seems to be more than 60 m, can't remember).
1. When the control is established, the direct use of "' Property name ', ' attribute value '" (such as ' CallBack ', ' Delete (GCBF), clearall;abc () ') will cause the program to not debug to reach its response function (seemingly calling itself cannot, call other functions can , not fully tested, hehe), the solution is to use message passing, ie ' CallBack ', @Action, and then write:
functionaction (hobject,eventdata,handles)
Delete (GCBF);
clear All;
ABC ();
2. There are two ways to implement a progress bar (probably more than one): Waitbar and Uicontrol, which can use two edit controls, or use the axes control plus the line function to generate, but either way, if each cycle is refreshed, Then, when the total number of cycles is large (such as hundreds of thousands of times), the running speed slows down, it is recommended to refresh every other distance (step), which can speed up the operation. For example:
if (i-100*k/n) <=1e-003
Waitbar (k/n);
i = i + step;
End
Where I is the control of the progress bar where the refresh, K is the program's loop variable, n is the total number of program cycles.
example of implementing a progress bar using the Uicontrol method:
copy content to clipboard
code: Figure;
E1 =uicontrol (GCF, ' style ', ' edit ', ' backgroundcolor ', ' W ',...
' unit ', ' normalized ', ' position ', [0.35,0.6,0.02,0.25]);
E2 =uicontrol (GCF, ' style ', ' edit ', ' backgroundcolor ', ' R ',...
' unit ', ' normalized ', ' position ', [0.3525,0.6,0.015,0.01]);
Drawnow;
n = +;
II = 1;
for i = 1:0.01:n
if (ii-100*i/n) <=1e-003
Set (E2, ' position ', [0.3525,0.6,0.015,0.01+0.24*i/n]);
Drawnow;
II = II + 1;
End
End "Appendix" to Cwit Brother:
the ten differences between M file and fig file creation figure--writing figure in code is not a hassle. If you are accustomed to, or familiar with, you will find code to implement guide programming, more convenient than the GUI, the function is also very powerful. Guide programming with M files has several differences compared to GUI programming:
1. Code can be reused, save cost;
2.GUI Cannot create uimenu flexibly, and cannot edit all its properties;
3.GUI has not been implemented to create uitoolbox;
4.GUI Cannot create sub-objects of all axes;
5. The Write interface also has some algorithms that cannot be implemented in the GUI. And the M file can be implemented in different window sizes to the appropriate position of the object;
6.m files can generate very complex interfaces;
7. Using GUI programming, the code compiles and relies on the *.fig file;
8.m files can implement components;
9.m files created by the object, you can easily access data in the handle;
10.m files can combine the creation of object code with the execution code of the action.
"Note" About two ways of running:
for Fig file mode: The fig file records the layout and properties of the control resource information, m file is the response message of the control (this is a personal understanding, more accurate introduction please refer to the GUI books, I am too lazy to check, hehe), both indispensable. Therefore, you cannot run the GUI by opening the fig file (such as the Open command in the menu), and there are two ways to run it: Open the M file for that GUI and run it like a normal m file Open the GUI's design Interface (menu operation: fileànewàguiàopenexisting GUI, open fig file。
[Reprint] A little bit of experience about Matlab GUI
