Problem with transfer information from a axes to another in GUI(using copyobj)

I always have some problem to transfer figure information (like curves or boxplots or something else...)...

I try to move it by adding

   fig= figure('visible','off');
   ax = axes;

right after the plot I've made, and using copyobj to transfer it by:

figure(1)
copyobj(handles.axes_ezplot,ax);

and it open a new Figure with what I want successfully.

But when i try to do the same thing to some axes in the same gui,like:

axes(handles.axes2)
copyobj(handles.axes_ezplot,ax);

It just failed with no Error or warning, the axes is still empty and nothing show up!

I try to save the information by .fig and copy it back to the axes but still don't work.

(Sometimes the new opened Figure Failed too with no image,but transport within axes never succeed.)

At the same time, I can only copy one object by using 1 copyobj code, if I get some complex figure (distribution curve,boxplot,....)，I can not copy it at one time. Is there a better way for doing this?

Also, it seems that the copyobj function can not be used twice, after I close the new-opened-Figure-window then try to do it(by repushing the button), just don't work anymore. But neither did I erase the original axes nor did I clear any other data(I already put the plot information into another handles (like handles.mydata)), why can't I use the data twice??

FULL TEXT OF MY CODE(simplified):

function varargout = test_of_axes_transfer(varargin)
% TEST_OF_AXES_TRANSFER MATLAB code for test_of_axes_transfer.fig
%      TEST_OF_AXES_TRANSFER, by itself, creates a new TEST_OF_AXES_TRANSFER or raises the existing
%      singleton*.
%
%      H = TEST_OF_AXES_TRANSFER returns the handle to a new TEST_OF_AXES_TRANSFER or the handle to
%      the existing singleton*.
%
%      TEST_OF_AXES_TRANSFER('CALLBACK',hObject,eventData,handles,...) calls the local
%      function named CALLBACK in TEST_OF_AXES_TRANSFER.M with the given input arguments.
%
%      TEST_OF_AXES_TRANSFER('Property','Value',...) creates a new TEST_OF_AXES_TRANSFER or raises the
%      existing singleton*.  Starting from the left, property value pairs are
%      applied to the GUI before test_of_axes_transfer_OpeningFcn gets called.  An
%      unrecognized property name or invalid value makes property application
%      stop.  All inputs are passed to test_of_axes_transfer_OpeningFcn via varargin.
%
%      *See GUI Options on GUIDE's Tools menu.  Choose "GUI allows only one
%      instance to run (singleton)".
%
% See also: GUIDE, GUIDATA, GUIHANDLES
% Edit the above text to modify the response to help test_of_axes_transfer
% Last Modified by GUIDE v2.5 29-Mar-2016 16:59:35
% Begin initialization code - DO NOT EDIT
  gui_Singleton = 1;
gui_State = struct('gui_Name',       mfilename, ...
                   'gui_Singleton',  gui_Singleton, ...
                   'gui_OpeningFcn', @test_of_axes_transfer_OpeningFcn, ...
                   'gui_OutputFcn',  @test_of_axes_transfer_OutputFcn, ...
                   'gui_LayoutFcn',  [] , ...
                   'gui_Callback',   []);
if nargin && ischar(varargin{1})
    gui_State.gui_Callback = str2func(varargin{1});
end

if nargout
    [varargout{1:nargout}] = gui_mainfcn(gui_State, varargin{:});
else
    gui_mainfcn(gui_State, varargin{:});
end
% End initialization code - DO NOT EDIT

function test_of_axes_transfer_OpeningFcn(hObject, eventdata, handles, varargin)
handles.output = hObject;
guidata(hObject, handles);

function varargout = test_of_axes_transfer_OutputFcn(hObject, eventdata, handles) 
varargout{1} = handles.output;

function pushbutton_Callback(hObject, eventdata, handles)
arrayfun(@cla,findall(0,'type','1'));           %clear figs in  all axes
syms x y
n=handles.n;
y=sin(n*x);
axes(handles.axes1)

handles.axes_ezplot=ezplot(y,[0,1]);
title off;

fig= figure('visible','off');
ax = axes;
guidata(hObject,handles);  

function edit1_Callback(hObject, eventdata, handles)
global Y xlabel_0to1  ax fig
handles=guidata(hObject);
n=handles.edit1;
handles.n=n;
guidata(hObject,handles);  

function edit1_CreateFcn(hObject, eventdata, handles)
if ispc && isequal(get(hObject,'BackgroundColor'), get(0,'defaultUicontrolBackgroundColor'))
    set(hObject,'BackgroundColor','white');
end

function pushbutton_ShiftPicToFigure_Callback(hObject, eventdata, handles)
global  ax 
figure(1)
copyobj(handles.axes_ezplot,ax);
axis([0,1 ,-inf,inf]); 

function pushbutton_ShiftPicToAxes_Callback(hObject, eventdata, handles)
global  ax 
axes(handles.axes2)
copyobj(handles.axes_ezplot,ax);
axis([0,1 ,-inf,inf]);

[Adam]

For a start you really shouldn't be using a global variable. It may not be the source of this particular problem, but it is far more likely to introduce bugs than other methods.

You already use the better way of doing this with:

handles.axes_ezplot=ezplot(y,[0,1]);

so do the same thing with your axes handle to share between callbacks, don't make it global.

[Cheng, Nestic]

Thanks for your reply!!

I don't really understand what's the different between using global variable and using handles... I usually use handles but I heard that it may also work by calling global variable in every function used it.

So I just tried both handles and global in this case,and both of them didn't work.

Is there a reason why using handles is better than global variables?

[Adam]

global variables just appear like magic in your workspace. They may be coming from literally anywhere, they may get changed literally anywhere or reset and are just generally very bad coding practice. You also have no real knowledge at any point exactly what global variables exist out there in the ether - you could easily overwrite one by giving another the same name just because you don't realise it exists. You can do this with handles and any workspace variable too, but it is far easier to find such bugs.

The handles structure also uses a little "magic" in that it's behaviour is not fully transparent to the programmer, but it behaves much better. The 'handles' struct is a struct that is attached to a specific GUI and made available to all GUI callbacks which is how it enables you to store data and retrieve it in other callbacks.

In usual programming data attached to handles can only be edited within that GUI so that it is better encapsulated. Of course, there are ways, using ugly functions like findall, in which you can delve into a GUI from externally, fish out its handles struct and edit it, if you are really determined to program badly! In general though it is just a much safer option.