Thread Subject: Programmatic GUI

So when one creates a GUI using GUIDE the handle structure is already created and allows the user to add in any variables he should wish and they will be passed from function to function without issue.

What is the best way to accomplish this in a programmaticaly created GUI (aka without guide). I am aware that global variables would be an option but this seems like a messy way to do things. There is also the option of nested functions that would seem to accomplish the task as well.

I guess I'm asking what is the best or most commonly accepted practice to accomplish the task of data sharing among functions in a programmaticaly created GUI? Could I implement a handle structure, like that used in guide, that would take user created variables, and how might that be accomplished? Are there any good tutorials out there on programmaticaly created GUIs? Thanks for the reply.

There are many ways to do what you want, and each probably has some advantages and disadvantages. There are two approaches here:

http://www.mathworks.com/matlabcentral/fileexchange/24861

which do not use globals, and do not store the handles structure with userdata, guidata or any of these. You may find these techniques useful. Good luck.

"Matt Fig" wrote
> There are two approaches here:
> http://www.mathworks.com/matlabcentral/fileexchange/24861

Hi Matt. I was looking at the GUI examples in your FEX submission mentioned above and I have a question for you about it. In (for example) GUI_11 you have the following:

function [] = ed_call(varargin)
[h,S] = varargin{[1,3]};

My attention was drawn to that, since I happened to be using an older version of Matlab, and this didn't work. I noticed I could get it to work, by adding the "deal" function. That is:
[h,S] = deal(varargin{[1,3]});

But whether you have the deal function in there or not, isn't this a somewhat cryptic way of calling the function? It seems much more straight forward to replace the two lines above with this single line:

function ed_call(h,arg2,S)

Not only does it work across versions, but it seems much clearer as well. You seem to think carefully about your programming style, so I suspect you had a reason for doing it the way you did, although I can't see it.

~Paul

"Paul Mennen" <nospam@mennen.org> wrote in message <ha6b90$lj1$1@fred.mathworks.com>...
> "Matt Fig" wrote
> > There are two approaches here:
> > http://www.mathworks.com/matlabcentral/fileexchange/24861
>
> Hi Matt. I was looking at the GUI examples in your FEX submission mentioned above and I have a question for you about it. In (for example) GUI_11 you have the following:
>
> function [] = ed_call(varargin)
> [h,S] = varargin{[1,3]};
>
> My attention was drawn to that, since I happened to be using an older version of Matlab, and this didn't work. I noticed I could get it to work, by adding the "deal" function. That is:
> [h,S] = deal(varargin{[1,3]});


Yes, I think in versions prior to 7.0, you will get an error here.


> But whether you have the deal function in there or not, isn't this a somewhat cryptic way of calling the function? It seems much more straight forward to replace the two lines above with this single line:
>
> function ed_call(h,arg2,S)
>
> Not only does it work across versions, but it seems much clearer as well. You seem to think carefully about your programming style, so I suspect you had a reason for doing it the way you did, although I can't see it.


Thanks for asking, Paul. There are several reasons why I use this approach, but first it must be understood that I don't try to say this is the best way above all others. With that in mind, here are the reasons I arrived at this approach.

1. I like the uniformity - it is visually appealing and easy to remember when writing callbacks that they all have the same argument list (varargin) and first line (the extraction).
2. Since all the data I use is in one structure, there is no need for a traditional argument list that might change as I add (or backtrack and remove) capabilities to (from) the GUI during development. I don't have to go back and put an extra argument in the callback property declaration and then in the callback function declaration, all I have to do is extract from the structure the handle or data I need when I need it.
3. M-Lint drives me nuts with the "the value passed in may not be used." This is usually in reference to the eventdata argument. I know I can turn it off, but I write GUIs for multiple machines and different people. I don't want to be changing their configurations constantly.
4. I have written automatic GUI M-File generating software which is fairly advanced (and not on the FEX) which would be too hard to implement consistently with multiple arguments. varargin is absolutely great here.
5. The usual case is that I don't explicitly extract h from S, so the statement is usually simply: S = varargin{3}. I may have gotten lazy on a couple of those example GUIs, but that is OK, someone may learn what varargin{1} is! ;-)
6. (As for why not use deal) Some of the GUIs I write are thousands of lines, instrument controlling and data reducing freaks running on older, slower computers loaded with the latest versions of MATLAB. deal, being an M-File, can be slow at times (not much I know). I once traced a hang-up I was having to just such a line (it was helping to cause a serial time-out), fixed it to the current system and never looked back.

Those are just off the top of my head. If you have any more questions (or suggestions) about the files, feel free to email me about them.