I've found, as my projects get bigger, it is easier to use a MATLAB class to control and manage a GUI instead of manipulating the standard Matlab gui mfiles.
I believe this style of GUI programming makes passing data around from different areas of gui much easier.
The functionality of this example is analogous to the built in Matlab example in GUIDE. This example is purely to show another way to solve the same problem. This example can be extended to many other applications.
Running command: gui_class_example()
% This exmaple shows how to use a MATLAB CLASSDEF to create, maintain, and
% destroy a gui.
% I chose to use one of the standard MATLAB guide default gui examples,
% this allows you to see the differences between the two methods.
% I prefer using classes to control gui's because as the project gets
% larger, I find it much easier to maintain, understand, and debug using a
% class bases sytem than using the traditional gui based system.
% Also, this method is great for passing data between elements of the gui.
% Since the class managed the gui, all gui elems are within memory scope of
% the class.
% Almost everything is the same between managing a gui through the gui
% mfile and a class. There are 2 main differences that I've noticed.
% 1. With the class based system, you do not need to store and set the
% guidata to obtain and pass data along
% 2. Cleanup is harder using the Class based system. There are 2 objects in
% memory, the gui itself and the class. These must be linked in some way
% that if one is closed or destroyed, the other is taken care of. I show
% one solution to this siutation here by adding a closerequestfcn to the
% figure. This function then calls the class's delete function to clean up
% the memory (preventing memory leaks).
The file standard_fig.m only exists as a "path" to the actual gui figure file. The contents of the file itself are irrelevant.
I normally leave all of the event handles in that file blank, to avoid confusion. establishing your own event handlers in your class function will overwrite any existing ones in the fig.m file. However, I am uncertain what will happen to events that are not rewritten. The 2 possibilities are that they exists and could still be used, or that they are completely ignored.
When I get a change, I will run a test to see what happens and reply again.
im working on making a gui as a class object, and i have a question about your code. is it necessary to write the functionality of the callback functions in standard_fig.m as well as in the mapped class function? this seems to add room for error with duplicate code. thanks!
Addendum to my last comment: deleting the owning object does close the figure; closing the figure window clears (don't know if that's the right word) the object, but the variable it was assigned to still exists. That's OK, but it could be confusing.
This is a wonderful idea! I will be using this approach for a database browser. However, the linking between figure and object doesn't work. Closing the figure does NOT delete the object, and deleting the object does NOT delete the figure. I tried some variations of your ideas - and the basic approach seems sensible - but something is preventing this to work. Is it the Matlab event handling?
It's Ok. I solved it. I was asking that how can we create two different GUI figure windows for two different instances of classes.
I did it by changing the singleton property of GUI figure to false
Could you rephrase your P.s. question? I'm not understanding what you mean.
You solved my problem by providing this file. i was trying to implement the GUIDE created GUI using object of class but it was reporting errors when any of the widgets on the GUI was clicked. This is a sound way of doing it. Thank you.
P.s. How can we have different windows of GUI when two different objects from the same class access the GUI.
It's brilliant idea. It seems extremely simple and effective. Thanks a lot.
The correct command line function is:
G = gui_class_example
Apparently, I needed to add the mfile for the fig as well. The command guihandles(handle) appears to define the figure handle based off of the mfile name, not the fig file name.
You can do this yourself by using Guide. However, the updated zip file should be on here shortly.
can you show me an example of running your code ? somehow I always get the following error message.
??? Undefined function or variable 'standard_fig'.
Error in ==>
this.gui_h = guihandles(standard_fig);
The mfile for the fig was added.