Handles in GUIDATA desappear when placed in 'CreateFcn'

Hey guys,

I've read other threads but couldn't find a solution.

The thing is, when I write a variable to handles in a 'CreateFcn', I can see it there if I put a breakpoint after

Guidata(hObject,handles);

But when I need that var when using the gui, it's not there.

What am I doing wrong??

This is where I create the function:

handles.data.e_pExt=uicontrol(  tab1,...
                                'Style','Edit',...
                                'String','[MPa]',...
                                'FontName','Arial',...
                                'FontSize',10,...
                                'Units','Norm',...
                                'Pos',[0.175,0.71,0.101,0.05],...
                                'Horiz','Center',...
                                'Callback', @(hObject,eventdata)...
                                            Copy_of_cylinder('e_pExt_Callback',...
                                            hObject,eventdata,guidata(hObject)),...
                                'CreateFcn',@(hObject,eventdata)...
                                            Copy_of_cylinder('e_pExt_CreateFcn',...
                                            hObject,eventdata,guidata(hObject))    );

This is where I save the data into handles (specifically handles.pAtm)

function e_pAtm_CreateFcn(hObject, ~, handles) %#ok<DEFNU>

if ispc && isequal( get(hObject,'BackgroundColor'),...
                    get(0,'defaultUicontrolBackgroundColor'))

    set(hObject,'BackgroundColor','white');

end
handles.pAtm=handles.data.pAtm_ini;
handles.data.e_Atm_chkvalue=true;
guidata(handles.cyl_fig,handles);

And as you can see, it's there when debugging (while oppening function is running)

But then, I need that var when editing the editbox and it's simply vanishes

Do you know why this happens?

Regards

[Adam Danz]

If the e_pAtm_CreateFcn is executed when the GUIDE GUI is initialized, the handles structure should be empty, I believe, and the call to handles.cyl_fig should throw an error since cyl_fig should not exist in the handles structure. At least that's what's happening when I test the create functions in GUIDE when a GUI initializes.

Furthermore, all of the Create Functions are run before Opening Function is executed and the Opening Function is the function that stores the handles in the GUI. Some something is fishy about the workflow you're describing unless there are some important details that were left out.

You should be getting an error message but the GUI should still appear to open.

[Rafael Barata]

I understand what you're saying.

In fact, I just used GUIDE to create the figure and start the m.file. The rest of the GUI I did programmatically.

Every object is created inside the opening function.

This is my first GUI and my first program so maybe this is not the best approach.

As you can see now, every CreateFcn is executed inside of the Opening function so the handles struct is already being filled.

The first image above is during the GUI's creation, inside opening fcn and the second is with the gui running when I edit the edit box. First the variable is there and then it's gone. I can't understand why.

Answer 1

[Adam Danz]

"This is my first GUI and my first program so maybe this is not the best approach."

Correct :)

You've definitely invested some time into this but I strongly urge you to move your GUI from GUIDE to either App Designer or to a GUI created from bottom up using uicontrol(). The time you'll save in the longrun and the skills you'll learn will be a much better investment of your time than continuing wiht GUIDE. Here are my reasons.

1) Matlab plans to stop developing and supporting GUIDE GUIs in future releases.

2) If you're using GUIDE just to create the figure and start the m-file, you're practically already using the same workflow you would use with the uicontrol() method. But since your GUI figure is initialized with GUIDE, it's doing a lot more work than necessary.

3) There's a lot of mysterious things that happen behind the scenes in GUIDE. If you use the uicontrol method, you have much more control of what's happening. App Designer is also more transparent than GUIDE, it offers less control but has more visual appeal and is easier to place objects in the GUI/App.

Here are two other threads that urge new users (all users, actually) to avoid using GUIDE. The contain advice how to transition in one of alternatives.

• https://www.mathworks.com/matlabcentral/answers/483657-how-to-create-a-gui
• https://www.mathworks.com/matlabcentral/answers/410672-app-gui-tutorials

[Rafael Barata]

"Correct :)"

I should have made that question earlier.

I also did it this way because GUIDE's interface does not have tabgroups and since I have started the file programming it, I kept it that way.

Ok. I followed your advice and created a new function cylinder_v2 so I could check if the problem persists.

It creates the gui but then I got errors at all 'CreateFcn' functions. I can't declare them like I did in guide m.file, can I?

For example:

handles.data.e_pExt=uicontrol(  tab1,...
                                'Style','Edit',...
                                'String','[MPa]',...
                                'FontName','Arial',...
                                'FontSize',10,...
                                'Units','Norm',...
                                'Pos',[0.175,0.71,0.101,0.05],...
                                'Horiz','Center',...
                                'Callback', @(hObject,eventdata)...
                                            Copy_of_cylinder('e_pExt_Callback',...
                                            hObject,eventdata,guidata(hObject)),...
                                'CreateFcn',@(hObject,eventdata)...
                                            cylinder_v2('e_pExt_CreateFcn',...
                                            hObject,eventdata,guidata(hObject))    );

It gives me the following error:

Error using cylinder_v2
Too many input arguments.
Error in
cylinder_v2>@(hObject,eventdata)cylinder_v2('e_pExt_CreateFcn',hObject,eventdata,guidata(hObject))
(line 153)

for each creatingfcn that I have.

How can I correct this?

[Adam Danz]

I followed your advice and created a new function cylinder_v2

Could I see the whole function copy-pasted or attached? It's hard for me to guess how the cylinder_v2 function is being called.

[Rafael Barata]

Of course... It's a bit long but I place it attached

What am I doing wrong with these callbacks? I would appreciate any advice to improve in my code. Since it's my first program, I know that there are a bunch of things that I'm doing "not the best way".

[Adam Danz]

I see. You're defining the callback and create function as if you're still running the GUI through GUIDE but they must be called differently outside of GUIDE; it's easier.

Here's some background

https://www.mathworks.com/help/matlab/creating_plots/callback-definition.html

For example, this callback at the top can been simplified to the one at the bottom.

handles.data.e_pInt=uicontrol(  tab1,...
    . . . . .
    hObject,eventdata,guidata(hObject)),...
    'CreateFcn',@() cylinder_v2 (hObject,eventdata,guidata(hObject))    );

handles.data.e_pInt=uicontrol(  tab1,...
    . . . . . .
    'Callback', @e_pInt_Callback);

[Rafael Barata]

Ok. I was complicating a lot. Now it's everything functional like it was with GUIDE but the problem persists.

I write the var when the edit box is created, save it in handles and on the next step (continuing from breakpoint) it's gone.

[Adam Danz]

Mind sharing the updated code? It will be quicker for me if I can just reproduce the problem locally.

[Rafael Barata]

Sure. I save the handle in line 794 (handles.pAtm).

The value is wrote and then it's not.

[Adam Danz]

The zip file only contains a jpeg and csv file.

[Rafael Barata]

My bad

[Adam Danz]

I looked at the first version of the m-file and I think I see what may be the problem.

When you store the handles, you should store them to the main GUI figure. You could store the handles in any GUI component but the main figure is a good idea because it will always exist as long as the GUI exists.

guidata(handles.cyl_fig, handles)

Then you can retrieve the handles when needed.

handles = guidata(gcf());

or

g = findall(0,'Tag','cyl_fig_v2');
handles = guidata(g)

[Rafael Barata]

But I'm doing that. At the end of almost every function, there's a:

guidata(handles.cyl_fig, handles)

and when the callback is triggered, I think I'm getting the handles data from guidata using

guidata(hObject)

as argument. Like this:

 handles.data.e_pInt=uicontrol(  tab1,...
                                    ......
                                    'Callback', {@e_pInt_Callback,...
                                                guidata(hObject)     },...
                                    'CreateFcn',{@e_pInt_CreateFcn,...
                                                guidata(hObject)      }   );

[Adam Danz]

There needs to be some cleanup and simplification.

Here's an incomplete example of how to structure the code. The main ideas are,

1. Create all of the GUI components and store their handles directly to the handles structure.
2. Set the callback functions after all components are created. This isn't requried but it's often helpful especially when you need to include GUI handles as inputs.
3. At the very end of the GUI-creation code, assign the handles structure to the GUI figure.

    handles.cyl_fig = figure();
    handles.ax_cyl_bckgrd_img = axes();
    
    % Images directory
    path= ...                                % *** Avoid using "path" as a variable name since it's a common command name. 
    % Place background image
    % Read main_fig background image and set it
    bckgrd_img = imread([path,'3.jpg']);     % *** Use fullfile(path,filename)
    handles.hi=image(handles.ax_cyl_bckgrd_img, bckgrd_img);
    % Set background image transparency and turn off axis
    set(handles.hi,'alphadata',0.2)
    handles.ax_cyl_bckgrd_img.XAxis.Visible = 'off';
    handles.ax_cyl_bckgrd_img.YAxis.Visible = 'off';
    
    handles.tg_margin=30;
    handles.tg=uitabgroup(handles.cyl_fig, . . .  );
    
    
    handles.tab1=uitab(handles.tg, . . .);

    % ASSIGN ALL CALLBACKS AFTER ALL COMPONENTS ARE CREATED.
     handles.tg.SelectionChangedFcn = @tg_SelectionChangedFcn; 
     
     % ASSIGN HANDLES TO FIGURE AT THE END OF GUI CREATION
     guidata(handles.cyl_fig, handles)
    
    % CALLBACK FUNCTIONS
    function tg_SelectionChangedFcn(hObject,eventdata) 
    % Get handles if needed
    handles = guidata(hObject.Parent); 
    % DO STUFF
    % ASSIGN HANDLES BACK WHEN NEEDED
    guidata(hObject.Parent, handles);

[Rafael Barata]

Ok. I was looking for an easier way since I had everything declared in every CreateFcn.

I changed all the code as you suggested.

Now I have every handles during the gui creation but, after that, when I'm interacting with objects, I'm not getting the structure. What I get is an empty one. There's still something that I'm not declaring or calling correctly.

Follows the actualized version. I left a breakpoint at line 844 (called when you change material's popup) and the line before that is without semicolon so you are able to see the result.

[Rafael Barata]

Problem solved! I was getting and setting handles from/to gcf. Then I change it to the figure's handle and it works. I thought it was the same but results it wasn't. Althougth that get(gcf) or get(handles.cyl_fig) prints the same result, handles=guidata(gcf) is not the same that handles=guidata(handles.cyl_fig). This I can't understand but my original doubt is solved.

Thanks for all your time and help. Best regards :)

[Adam Danz]

Good work! In general, only use gcf, gca, gco, etc when you have no other alternative.

If you have any other questions about making the GUI I'd be happy to help.