GUIDE code from pre 2015 need to access the button press function and "programatically press the button" from a different m file

Hey All

As the title suggests, I am dealing with a GUIDE file from a long time ago and I need to have it running and while its running I want to be able to access one of the functions called SaveSpectrumPlotButton_Callback() on line 1933

I have not been able to find how to access it from a different file or even create an output that I could maybe access in order to activate that button. I have shared the m file below

Any help would be much appreciated/

[Steven Lord]

Let's take a step back. What is your workflow where you need to programmatically trigger this local function that's intended to be triggered by an interactive part of a workflow (actually clicking on the button)? Perhaps we can suggest how to achieve your goal in a different way.

[Bera]

Hey Steven first off thanks. Secondly, I am a co-op working on this code that was given to me and to be frank its quite disorganized. In summary, the code itself is a live updating camera that feeds information to a spectroscope and makes a plot of the peak and then to save this data a button called save plot has to be saved. The issue arises that I am automating a giant process of quantum dots be excited and the light being extracted. So I have to implement this code into there i.e. I have to have the main function running while I can "progammitcally press" the save button every time I'm positioned on a new quantum dot

[Bera]

Answer 1

[Fangjun Jiang]

In the .m file created for your GUIDE application, there is a function called SaveSpectrumPlotButton_Callback() defined. Currently, it is a local function. Other .m file outside of the FWHM_ver_Richard.m file can not call it.

I think you can cut the code for SaveSpectrumPlotButton_Callback() out and make it a separate SaveSpectrumPlotButton_Callback.m file. Then you can call this function from anywhere.

Calling it from other .m file will be equivalent as " programatically press the button".

[Bera]

Would it be that simple though? Since doesn't the function have to be within the GUI so that the button properties behave as expected?

[Bera]

@Fangjun Jiang Like doesn't it need a bunch of external properties to behave as expected?

[Bera]

and the original file is a GUI so if I cut something out of it Im not fully sure I'll be able to press the save button

[Fangjun Jiang]

I am pretty sure it will work. Whether it is the best way is a different question.

You can even not make any changes to your original file. Just copy that function and make it a separate function and then try it.

[Voss]

You'll need to provide the correct arguments to the SaveSpectrumPlotButton_Callback function.

% store the main figure handle when the program is run
hFig = FWHM_ver_Richard();

% then, when you call the plot button callback, provide the arguments it expects
SaveSpectrumPlotButton_Callback(hFig,[],guidata(hFig))

[Bera]

@Voss Thanks Voss I was just going to ask though, the FWHM_ver_richard function in the original function file already has an output. Are you suggesting to call it in a new m file with a new output and if so will that assign it to the figure? Additionally, the inputs you provided are you saying I need to change those or are those the perimeters I would use for calling? Thanks again

[Voss]

@Bera You're welcome!

I am not suggesting to change anything about the m-file you posted. I am only saying that, if you copy the SaveSpectrumPlotButton_Callback function into its own m-file, with the function itself unchanged, as @Fangjun Jiang has suggested, then you need to call it with the proper inputs:

1. the figure itself (which is called hObject in SaveSpectrumPlotButton_Callback)
2. the second argument (called eventdata in SaveSpectrumPlotButton_Callback) is unused, so you can pass anything; I suggested to pass an empty array []
3. the guidata of the figure (called handles in SaveSpectrumPlotButton_Callback)

Now, you point out that FWHM_ver_Richard has an output already, and that is true. Its output is the figure itself, referred to as handles.output in FWHM_OutputFcn. See the excerpt below (comments I added are preceded by "<----"):

% --- Outputs from this function are returned to the command line.

function varargout = FWHM_OutputFcn(hObject, eventdata, handles)

% varargout cell array for returning output args (see VARARGOUT);

% ...

varargout{1} = handles.output; % <---- the output of FWHM_ver_Richard is handles.output

And handles.output is set to hObject in FWHM_OpeningFcn, where in that context hObject refers to the figure. Here are the relevant lines of FWHM_OpeningFcn:

% --- Executes just before FWHM is made visible.

function FWHM_OpeningFcn(hObject, eventdata, handles, varargin)

% This function has no output args, see OutputFcn.

% hObject handle to figure % <---- hObject is the figure

% ...

handles.output = hObject; % <---- so handles.output is the figure

% ...

Again, no changes need to be made to the code; you only need to store that output to some variable (I called it hFig) when FWHM_ver_Richard is run, and pass that same variable to SaveSpectrumPlotButton_Callback (along with guidata(hFig) as the third input).

[Bera]

This is all amazing thanks @Voss I was busy in the lab so I didn't have the time to thank you!

[Rik]

One minor note: hObject is the handle to the callback object (in this case the button). Passing in the figure may or may not work. You should probably pass in the button handle instead (it will be a field of the guidata).

[Bera]

@Voss @Rik I had a question since the save button function alo uses another function called savegraph from the code would i have to define that in a seperate m file as well or would it be able to just call it because were passing handles to guidata

[Fangjun Jiang]

I would suggest copying that function into SaveSpectrumPlotButton_Callback.m file to make it a local function of that file. Hope that is the end of the chain dependency.

[Bera]

Yup that should work

[Voss]

@Bera: @Rik is correct that hObject in the function SaveSpectrumPlotButton_Callback refers to the button object. However, passing the figure instead of the button will work in this particular case because of how hObject is used in SaveSpectrumPlotButton_Callback (it's only used in guidata - which behaves the same whether you pass a figure or a descendant of the figure - and it's passed to SaveGraph, which doesn't use it), so the syntax I suggested initially should work (provided SaveGraph is an accessible function, as you point out).

[Bera]

@Voss Hey Voss you are very knowledgeable so I wanted to ask. When I'm calling savegraph a function inside the savebutton, would I also have to define that in a seperate m file and if so when I'm calling it what functions would I have to call that with?

[Image Analyst]

The callback function for the Save button, savebutton_Callback(hObject, eventdata, handles), would of course be in the main GUI's m-file. That callback function can either call code right there inside that function (no second m-file needed), OR could simple make a one line call to another m-file, savegraph.m, which has the code in it. If it's in a second function file, or even if it's in the main m-file, make sure that if the savegraph() function needs any input arguments to be passed to it that the input arguments are in scope so that savegraph() can see and use them.

[Bera]

@image analyst I had understood that I would be able to call the savebutton function in a different m file using what voss had recommended no? I was then wondering if I would have to somehow save the savegraph button in some different way as well or if that wasn’t required

[Fangjun Jiang]

SaveGraph() is defined as SaveGraph(hObject, handles). It is called only once inside SaveSpectrumPlotButton_Callback(hObject, eventdata, handles).

Making SaveGraph() a separte SaveGraph.m file, or keeping SaveGraph() inside the SaveSpectrumPlotButton_Callback.m file would make no difference for functionality.

I would choose the latter. As you are adding stuff to your existing working GUIDE application, less intrusive, less new files would be better.

[Bera]

I see thank you Fangjun! I don’t want to close this question yet since I’m worried somethings may arise but during the meantime I appreciate everyone who answered my questions!

[Bera]

@voss @Fangjun I just wanted to make sure since I haven’t used GUIDE before. Calling the savebuttonfunc is the same as the button being pressed right? As in I can call it multiple times to take a photo every time? Like would ai have to set a button value to 1 similar to app designer or would it work just by calling the function?

[Voss]

You can just call the function. There is no need to set the button's Value.

Also, SaveGraph has to be a separate m-file function in order to be accessible outside the GUI.

[Bera]

@voss oh does it. Everyone is saying different things, so I would have to make a new m file with it then right?

[Fangjun Jiang]

@Voss

A SaveSpectrumPlotButton_Callback.m has been created by copying the SaveSpectrumPlotButton_Callback(hObject, eventdata, handles) function from the original GUIDE .m file. My suggestion is to copy SaveGraph() function into the SaveSpectrumPlotButton_Callback.m file. SaveGraph() does not have to be a separate m-file in this context.

[Voss]

That's right. Having SaveGraph as a local function in SaveSpectrumPlotButton_Callback works. I misunderstood what you were suggesting.

[Voss]

@Bera: Perform tests, and keep track of what happens. That's the way to figure something out.

[Bera]

Okay thank you so much guys! I was just handed this code myself so I don’t know it in too much depth, what handles would I give savegraph as a local function would it be the same or different ones then the original m file

[Fangjun Jiang]

SaveGraph(hObject, handles) is called inside of the SaveSpectrumPlotButton_Callback(hObject, eventdata, handles) function. As long as the (hObject, eventdata, handles) is specified correctly for SaveSpectrumPlotButton_Callback(hObject, eventdata, handles), you don't need to do anything extra.

[Voss]

Same.

[Bera]

@Voss@Fangjun Jiang any clues as to why this may be happening

Answer 2

[Image Analyst]

I agree with @Steven Lord that you should just rethink and reorganize the workflow. That said, please read the FAQ for ideas on how to control one GUI from another:

https://matlab.fandom.com/wiki/FAQ#How_can_I_share_data_between_callback_functions_in_my_GUI(s)?

especially the section that begins "Sharing between multiple GUIs."