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.
Related
I have created several figures in Matlab (using GUIDE) which act as a config-GUI for a model. The idea is that changes made in figure F1 should affect what choices can be made in figure F2, F3, .... However, there are 5 figures, all holding different information, and it is possible to navigate arbitrarily between the figures (push buttons on each figure, to every other figure).
A large issue is that I want only one figure to be open at any point in time. That is, when F1 has started FX, I want F1 to close. Hence, I think it is unsuitable to use global variables. (?)
My issue is that I am simply not capable of holding all the data up to date. Maybe this could be achieved using appdata or guidata, but I cannot wrap my head around it.
Examples:
Since the handles of F1 and F2 differs, passing F1.handles to F2 works (F1.handles shows up in varargin{1} in F2), but I cannot concatenate F1.handles with F2.handles. Hence, I have no apt way of sending F1.handles and F2.handles to F3 (or any other figure). (If this can be achieved in a more simple way, I might be okay with dropping the "arbitrarily navigation feature", but so far I have not been able to make it work.)
Using .mat-files (i.e., write FX.handles to a file and load each file in each Figure) seems such bad practice that I haven't even given it a serious go.
So far, I have not found it necessary to change the data in FN±X from FN, hence I guess the .mat-file approach could work, but my latest idea is using Matlab OOP and pass around a class instead of the handles. I found an old post on the topic (Global (shared) variables in Matlab GUI code behind. Is there better way to do it then using handles structure?) but it links merely to a File Exchange and I am unable to understand how to make it applicable for my use case.
Edit 1: I found this Using GUIDE with object-oriented MATLAB?, and will give it a try, but I am still having a hard time understanding exactly how to use it, since it seems to require using handles anyway.
U can try using global variables to retrieve handles for all the figures created by assigning handles values to a global variable in a structure format. Global variable persists in memory until you close the figures.
i have four variables which two of them,named 'lat' and 'long' get value in a popup, and two others, named 'lat1' and 'long1', which get value in the same way in a different popup menu and this four, finally would be used in a third popup menu.
first i tried global variables but didn't work at all, then i tried handles structures and read every thing about it and read everything about sharing data and value between functions and callbacks and every question in stack overflow around this topic but it didn't help me.
It's hard to know exactly what you need from your description, but I'll guess that you have a main GUI and are using separate pop-ups to get inputs? I think from what you have said, you are on the right track.
The handles variable is what you want. It is really useful for sharing data throughout a GUI (if you have used GUIDE to set up your GUI environment then handles should be available, if not then you will have to set it up yourself by calling guihandles - more details here). If you save your variables into it, e.g.
handles.long = ..., handles.lat = ...
and update the variables with guidata(hObject,handles) then you should be able to access handles.long and handles.lat throughout your GUI.
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!
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 have a MATLAB GUI that loads to aid in visually pre-processing data. Essentially it prompts the user to adjust the data range, reduce number of data points, etc... all while providing an updated graph. Upon completion of this work, I want to be able to close out the GUI and pass variables from the GUI to another MATLAB function that does the data analysis. I have found lots of information on how to pass information from a function TO and GUI, but not the other way around.
Any help would be greatly appreciated.
Global variables can cause hard to find bugs. The best solution for your problem (where you want to pass the data directly to another function on close) might be to call the analysis function from the Figure Close Request Function. When the figure your GUI is running in is told to close, it will run the code in this function, which can call your analysis function and have access to the GUI's data.
Matlab GUIs are functions: the code exists in a .m file just like other functions. Like regular functions, they can have return values. You can get as fancy as you want messing with the varargout system, or you can simply return a value, structure, or cell array containing whatever you want. Open up the m-file and edit it to return what you want it to.
Note: If you require special processing when the figure is being closed to generate the appropriate return value, you can reimplement the closeRequestFcn as you see fit.
The easy way: you declare as global variable, where variable stores the data that you want to carry from the GUI to the main MATLAB workspace. Then, you also declare the same global variable on the command window. Hereinafter, variable to be accesible from both scopes, the GUI and the main workspace.
You could also use save or any other alternatives as csvwrite or dlmwrite to store the data into a file, but this doesn't seem to be your case.