General Q: Why Matlab doesn't end (close) the function when you create an object in the GUI

Hello All,

I just wonder why Matlab doesn't end the function (callback for instance) of any object in a GUI when created! For example, after you save the GUI, the following code will be generated in the code file without an end:

function x_callback(...)
...

% hence without an end

Another question, when you create a text field in the GUI, isn't necessary to keep the two automatically generated functions, i.e the callback & createfcn? is there a way not to have them in the code?

Thanks & Regards

[AND]

Both answers are very helpful, but I got to choose one and it would be Image's as it arrived first- Many thanks Walter for your detailed answer, it is indeed very helpful

Answer 1

[Image Analyst]

That's just the style it chose. The end statement is optional - you don't need it. But if you want to use it, you can. But if one function uses it, then all functions have to use it. You can't mix styles in the same m-file.

When you place a control on the GUI, it will make the create function. If you ask to see the callback, it will make that too. With old versions of MATLAB (a few years old), you had to leave the create function in there, but I believe with more recent versions you can delete the create function without any harm. Make a copy of the m-file, then try deleting it and see if it still works. I think it will.

Answer 2

[Walter Roberson]

You are not really asking about MATLAB itself: you are asking about GUIDE, which is a tool useful to generate MATLAB code.

Image Analyst mentioned that using "end" statements is optional. That is a bit of a simplification:

1. methods in objects must always use "end" (objects can only be defined in "class" files)
2. nested functions must always use "end"
3. if any routine in a file (including a nested function) uses "end", then all routines in a file must use "end"
4. if "end" is used, then there is a difference in compilation and execution. If "end" is not used, then new variables can be "poofed" into existence at any time, including by running scripts that create variables, or by "assignin" or "evalin". When "end" is used, then a "static workspace" is created in which variables can only come into existence by way of assignment statements at that level, with poofing not being allowed; this allows for better optimization. Such workspaces also form closures

My speculation for the last couple of years has been that GUIDE does not add the "end" because if it did so, it would be necessary to re-validate the code (and possibly fix portions of it) to take into account the static workspace rules. As GUIDE was never designed really designed for efficiency anyhow, the additional efficiency and error checking of using the "end" is probably not worth the effort of building new test cases and rejigging the code (and putting in another backwards compatibility mode to allow people to use the old style.)

[Jan]

A trailing end is not valid in older Matlab versions, e.g. in 6.5. So omitting the end might support backward compatibility.

[Sean de Wolski]

Jan's comment on backward compatibility is the main reason. The "end" is new in MATLAB 7 I believe.

Personally, as a best practice, I always use ends - even in GUIDE files.

The MATLAB Class system requires ends as well.

[Walter Roberson]

Sean, GUIDE is not currently backwards compatible to MATLAB 6, as it can generate objects that cannot be properly initialized even in some previous MATLAB 7 versions.

Answer 3

[AND]

Thanks a lot guys - your contributions are very valuable to me

Now I don't know which answer I should choose, because Image provided it first, but Walter elaborated on it- any suggestion please?

Thanks again and all best//

[Jan]

Accept one, votethe other and mention in the comment section, that both help to solve your problem.