Say, I have two following files:
A.m with matlab code that contains function callbacks and
A.fig with corresponding user interface file.
Now, I'm making copy of these two files:
A_copy.m
A_copy.fig
These two files were created by just copying the first ones. Now the questions is, why debugger does not stop inside callbacks? Inside other function debugger stops in its normal way, but not in callbacks. Of course, I've changed function name in A_copy.m from A to A_copy.
Which problem may I face?
Thanks.
Oh my God.
To fix this problem I had to go to main window editor properties and change NAME property. Just a string that contains title of the gui window. Why? Why? Why, Mathworks, WHY?
I can't believe it is made in so stupid way!
Related
I'm currently learning MATLAB's GUIDE gui programming. I notice that when I place some objects in a figure, a corresponding 'CreateFcn' callback function is creating in the associated .m file. MATLAB's comments state that this function is executed when the object is created (I would consider this a constructor for the object).
However, I've noticed that not all objects seem to have this 'CreateFcn' constructor. Static text objects do not appear to have this callback function. And as of currently, it seems like this function just makes the code more difficult to read. Thus I'm curious if I can delete.
By deleting it, I tend to get an error in my code stating that the function can't be found. So my question: is it possible to delete the 'CreateFcn' method to declutter my code?
Thanks,
Surely it is possible.
Double-click the object to open up the inspector window, locate the "CreateFcn" property and set its value to an empty string. Then go to the .m file and remove the code of CreateFcn. This way MATLAB wouldn't complain about the missing CreateFcn anymore.
CreateFcn is not really a constructor per se, since it happens after all properties of the object are already set. It is more like an optional post-constructor event that gives user an opportunity to further customize the object's initial behavior dynamically. For example, you can customize the object's color at creation depending on the background color on which the object appears. For most control objects, the default behavior is probably already good enough for you. So you can safely remove those CreateFcns until you find a good excuse to use one.
1) Goto the View --> Property Inspector
2) expand the Creation and deletion control, remove the text from CreateFcn and DeleteFcn 3) close the property inspector save the respective GUI (Don't forget to save)
4) remove the callbacks in m-script.
Recently I've tried to use a custom performance function for NN in Matlab. What I did as an initial experiment, I took mse template and copy these files to my Matlab working directory. After that I renamed +mse folder and mse.m to mymse.m, leaving everything else(the code inside) unchanged. After that when I attempt to run NN tools with this new custom function(which is actually fully equal to the old one), Matlab randomly crashes.
And I don't mean exceptions. I mean Access Violation errors that kill Matlab instance.
When Matlab does not crash, it gives normal results.
Has anyone come across this problem?
Thank you.
you have to include the parent folder which +name folder is in.
Even if that parent folder is your current folder, it does not mean that it is included.
So, rigth click to the parent folder, and 'add to path'. This may be one of the reason that it crashes.
also, another thing that you have to keep in mind:
when trainin with custom performance functions, you may need to use train(net,x,t,nn7) instead of train(net,x,t) or you may get just zeros for output.
I am doing a group project and we are supposed to be using GUIS to create a presentation. In the presentation there is data that is loaded in using an edit text box and our code then goes through calculations and if statements and is supposed to pass certain values to a different GUI. Our instructors do not know how to do it because we have asked them on several occasions and they cannot figure it out. We have tried varargin method and the getappdata method and neither one is working. Does anyone have suggestions? PLEEAASE!!
I would write some "Controller" program that will know open the figures for you and know how to forward the data. Basically it would be a simplified mvc-pattern. It could also assure the figures are opened in correct order.
I have been reading someone else's matlab code and I don't know how the code structured. I mean I would like to know the hierarchy of functions, which function uses which function. I am reading the code to figure that out but its taking a lot of time.
So is there any other way I can see this hierarchy without reading the whole thing? To be honest it is starting to get confusing. Maybe MatLab has a built in function for that! I found this:
How can I generate a list of function dependencies in MATLAB?
but this doesn't seem to be helpful!
The MATLAB profiler will show you what functions are called by your code (and much more information to boot) and allow you to click through the hierarchy of function calls. You can either call profile on and then run your code, then call profile off and profile viewer, or you can simply call profile viewer and type a single line of code to run in the edit box at the top.
Use the dependency report provided in MATLAB:
http://www.mathworks.co.uk/help/matlab/matlab_prog/identify-dependencies.html
There are also some tools on the File Exchange, such as fdep.
No idea about a function to show visible or depended-upon functions. However the basic rules are:
1) Only the first function in a .m file (normally has to have the same name as the file itself) is visible outside that file.
2) Any function can see any top level (see 1.) function if the file is in the matlab path. Matlab can show you the path so you know where it's hunting.
3) The order of the path is important, the first instance of a function called foo found in the path will be called. Obviously the current directory is at the top of the path.
3) All functions in a given file can see all other functions in that file.
That's the basics. No doubt there are other rules, and possibly exceptions to this. But that understanding generally serves me well.
Obviously the easiest way to work out which function is being called is to click on it in the editor and open it.
One thing I do is simply place in each function at the beginning fprintf("inside function <name>/n"); and at the end of the function fprintf("leaving function <name>/n"); where <name> is the name of the function.
This will give you a very specific list of which function is being called by which function (based on the order that they appear). Another thing like this would be to place fprintf("function <name1> calling function <name2>/n"); so you can be more explicit about which function is being called by which one.
I am trying to put some .fig and their corresponding .m files in package.
I have:
+ui/mainWindow.fig
+ui/mainWindow.m
But when I try to run mainWindow.fig Matlab prints an error from GUIDE:
Error using feval
Undefined function or variable mainWindow
The funny thing is that if i call with its fully qualified name:
ui.mainWindow
the window appears normally (but all callbacks don't work anyway).
I have tried to import ui.* before running it.
Please note that I want to do this as sort of namespace. I don't want to have my entire application in the global scope of Matlab.
Explanation
The fundamental problem is that MATLAB GUIDE is unaware of packages. Normally, it manages the callback names automatically, keeping the .m and .fig files synchronized, and everyone is happy. When the figure is within a package, it fails to properly update the callbacks in the .fig properties - these still point to the unqualified name mainWindow rather than the correct ui.mainWindow. Subsequently, all callbacks fail.
Workarounds
Two ways around this one:
Export your figure: Guide -> File -> Export. Place this file within your +ui folder. Open the file, and do a find-replace replacing all instances of #(hObject,eventdata)mainWindow with #(hObject,eventdata)ui.mainWindow.
Alternatively, you can manually update the references directly within GUIDE itself, without exporting. For each button and element, Right Click -> Property Inspector then edit the 'Callback' field, replacing mainWindow with ui.mainWindow.
Personally, I prefer the first solution because you can replace all occurrences with a single find-replace command.