Thread Subject: How to insert a variable as a cell array in GUIDE?

Hei,

I would like to insert a variable in GUIDE which needs to be written in cell array for post-calculation! After running GUIDE this variable needs to be in following form,e.g.

A={[1] [2] [2 3]}

so that the different elements from the cell array can be acquired.

Is it possible to do it any other way than implementing a table?

Thank you kindly!
Grega

If it's just

> A={[1] [2] [2 3]}

you want then you could get the user to input [1] [2] [2 3] into an editbox and then extract the string and make it a cell in your gui code.

-qooroo

"qooroo " <qoorooAT@gmailDOT.comREMOVECAPS> wrote in message <h85npi$ee8$1@fred.mathworks.com>...
> If it's just
>
> > A={[1] [2] [2 3]}
>
> you want then you could get the user to input [1] [2] [2 3] into an editbox and then extract the string and make it a cell in your gui code.
>
> -qooroo

I tried it and would be great if it works...but it does not:

>>A='{[1] [2] [2 3]}'
A =
{[1] [2] [2 3]}
>> str2num(A)
ans =
     []
>> A='[1] [2] [2 3]' % without { }
A =
[1] [2] [2 3]
>>str2num(A)
ans =
     1 2 2 3
...but what I need is: A={[1] [2] [2 3]}.

Hope there is a solution.
Thank you!
Grega

editbox gives you a string, so you need to convert string to cell:

doc cellstr

so if your string from your editbox is

A = '[1] [2] [2 3]'

then you want

A = cellstr(A)


-qooroo

On Sep 8, 10:33 am, "qooroo " <qooro...@gmailDOT.comREMOVECAPS> wrote:
> editbox gives you a string, so you need to convert string to cell:
> [snip]

------------------------------------------------------------------------------
That's what I thought. But it depends on what version you're using.
In R2008b I was getting strings, but now I'm using R2009b(pre-release)
and it's returning a cell array and so I need code like this:
selectedRegionName = get(handles.edtRegion3, 'string');
% It seems that in version R2009b, they changed from returning a
string (as in R2008b) to a cell array.
if iscell(selectedRegionName)
selectedRegionName = selectedRegionName{1};
end

I'm not sure how it will end up in the release version of R2009b, nor
do I know if it had already changed to cell arrays in R2009a since I
have not used that version.
It certainly would be easier if the edit fields just returned a simple
string like you'd expect!

ImageAnalyst <imageanalyst@mailinator.com> wrote in message <1d7369c1-bc71-49bb-82bf-34f76b030eea@y9g2000yqn.googlegroups.com>...
> ------------------------------------------------------------------------------
> That's what I thought. But it depends on what version you're using.
> In R2008b I was getting strings, but now I'm using R2009b(pre-release)
> and it's returning a cell array and so I need code like this:
> selectedRegionName = get(handles.edtRegion3, 'string');
> % It seems that in version R2009b, they changed from returning a
> string (as in R2008b) to a cell array.
> if iscell(selectedRegionName)
> selectedRegionName = selectedRegionName{1};
> end
>
> I'm not sure how it will end up in the release version of R2009b, nor
> do I know if it had already changed to cell arrays in R2009a since I
> have not used that version.
> It certainly would be easier if the edit fields just returned a simple
> string like you'd expect!

that's odd. surely the behaviour of

get(hObject,'String')

under editbox callback is the same, I mean it can't give you something other than a string...

-qooroo

On Sep 9, 3:17 am, "qooroo " <qooro...@gmailDOT.comREMOVECAPS> wrote:
> ImageAnalyst <imageanal...@mailinator.com> wrote in message <1d7369c1-bc71-49bb-82bf-34f76b030...@y9g2000yqn.googlegroups.com>...
> > ---------------------------------------------------------------------------­---
> > That's what I thought.  But it depends on what version you're using.
> > In R2008b I was getting strings, but now I'm using R2009b(pre-release)
> > and it's returning a cell array and so I need code like this:
> >    selectedRegionName = get(handles.edtRegion3, 'string');
> >    % It seems that in version R2009b, they changed from returning a
> > string (as in R2008b) to a cell array.
> >    if iscell(selectedRegionName)
> >            selectedRegionName = selectedRegionName{1};
> >    end
>
> > I'm not sure how it will end up in the release version of R2009b, nor
> > do I know if it had already changed to cell arrays in R2009a since I
> > have not used that version.
> > It certainly would be easier if the edit fields just returned a simple
> > string like you'd expect!
>
> that's odd. surely the behaviour of
>
> get(hObject,'String')
>
> under editbox callback is the same, I mean it can't give you something other than a string...
>
> -qooroo-
------------------------------------------------------------------------------------------------------------------------------------------------------------

qooroo:

You'd think. But no. Here's my code from R2009b prerelease to test
what you suggested:


%=====================================================================
function edtRegion1_Callback(hObject, eventdata, handles)
% hObject handle to edtRegion1 (see GCBO)
% eventdata reserved - to be defined in a future version of MATLAB
% handles structure with handles and user data (see GUIDATA)
% Hints: get(hObject,'String') returns contents of edtRegion1 as text
% str2double(get(hObject,'String')) returns contents of
edtRegion1 as a double
strRegionName = get(hObject,'String');
caRegionName = get(handles.edtRegion1, 'string');

When I check strRegionName and caRegionName in the workspace, guess
what?
It says they're both 1 by 1 cell arrays.
-ImageAnalyst

ImageAnalyst <imageanalyst@mailinator.com> wrote in message <ed3aa391-7ff3-4709-9c8b-7194af86a261@r9g2000yqa.googlegroups.com>...
> You'd think. But no. Here's my code from R2009b prerelease to test
> what you suggested:
>
>
> %=====================================================================
> function edtRegion1_Callback(hObject, eventdata, handles)
> % hObject handle to edtRegion1 (see GCBO)
> % eventdata reserved - to be defined in a future version of MATLAB
> % handles structure with handles and user data (see GUIDATA)
> % Hints: get(hObject,'String') returns contents of edtRegion1 as text
> % str2double(get(hObject,'String')) returns contents of
> edtRegion1 as a double
> strRegionName = get(hObject,'String');
> caRegionName = get(handles.edtRegion1, 'string');
>
> When I check strRegionName and caRegionName in the workspace, guess
> what?
> It says they're both 1 by 1 cell arrays.
> -ImageAnalyst


that's terrifying. and would make quite a few of my guis bad. just for example string concatenation,

strRegionName = get(hObject,'String');
strFull = [strRegionName '_please let me be one string']

would give a 1x2 cell, not a complete string. surely it's a bug?

-qooroo

[snip]
>
> strRegionName = get(hObject,'String');
> strFull = [strRegionName '_please let me be one string']
>
> would give a 1x2 cell, not a complete string. surely it's a bug?
>
> -qooroo

Nope, concatenating two char arrays with brackets has always produced a larger char array.

See http://www.mathworks.com/access/helpdesk/help/techdoc/index.html?/access/helpdesk/help/techdoc/matlab_prog/f10-60825.html&http://www.mathworks.com/cgi-bin/texis/webinator/search/

Chris

On Sep 9, 10:44 am, "qooroo " <qooro...@gmailDOT.comREMOVECAPS> wrote:
> ImageAnalyst <imageanal...@mailinator.com> wrote in message <ed3aa391-7ff3-4709-9c8b-7194af86a...@r9g2000yqa.googlegroups.com>...
> > You'd think.  But no.  Here's my code from R2009b prerelease to test
> > what you suggested:
>
> > %=====================================================================
> > function edtRegion1_Callback(hObject, eventdata, handles)
> > % hObject    handle to edtRegion1 (see GCBO)
> > % eventdata  reserved - to be defined in a future version of MATLAB
> > % handles    structure with handles and user data (see GUIDATA)
> > % Hints: get(hObject,'String') returns contents of edtRegion1 as text
> > %        str2double(get(hObject,'String')) returns contents of
> > edtRegion1 as a double
> >    strRegionName = get(hObject,'String');
> >    caRegionName = get(handles.edtRegion1, 'string');
>
> > When I check strRegionName and caRegionName in the workspace, guess
> > what?
> > It says they're both 1 by 1 cell arrays.
> > -ImageAnalyst
>
> that's terrifying. and would make quite a few of my guis bad. just for example string concatenation,
>
> strRegionName = get(hObject,'String');
> strFull = [strRegionName '_please let me be one string']
>
> would give a 1x2 cell, not a complete string. surely it's a bug?
>
> -qooroo-

------------------------------------------------------------------------------------------------------------------------------------------
Even the Mathworks tech support folks were surprised. They're the
ones who told me to use iscell() workaround to check so that it would
work for any version. I'll send it in as a bug report. But with my
license lasting only about 20 days, the new release is about to come
out within that time I imagine, so I'm not sure it will make it in if
they don't already know about it. I notified them of another bug a
couple of weeks ago and they said that they couldn't fix it in time.

What you said was right (I think Chris misunderstood). I ran your
code in R2009b and verfied that it is, in fact, a 1 by 2 cell and you
do not have one long string. I am not sure why they decided to make
this change. Unless they fix this, you'll be implementing the
workaround like I did to have your old m-files run in the new
version. Maybe Steve Lord has some inside info on this????
-ImageAnalyst

Sorry, my bad, I only skim-read. What about using eval?

Chris

"ImageAnalyst" <imageanalyst@mailinator.com> wrote in message
news:d0dea7e2-a6c0-4115-829b-d7192b8901fc@p10g2000prm.googlegroups.com...
> On Sep 9, 10:44 am, "qooroo " <qooro...@gmailDOT.comREMOVECAPS> wrote:
> > ImageAnalyst <imageanal...@mailinator.com> wrote in message
> > <ed3aa391-7ff3-4709-9c8b-7194af86a...@r9g2000yqa.googlegroups.com>...
> > > You'd think. But no. Here's my code from R2009b prerelease to test
> > > what you suggested:
> >
> > > %=====================================================================
> > > function edtRegion1_Callback(hObject, eventdata, handles)
> > > % hObject handle to edtRegion1 (see GCBO)
> > > % eventdata reserved - to be defined in a future version of MATLAB
> > > % handles structure with handles and user data (see GUIDATA)
> > > % Hints: get(hObject,'String') returns contents of edtRegion1 as text
> > > % str2double(get(hObject,'String')) returns contents of
> > > edtRegion1 as a double
> > > strRegionName = get(hObject,'String');
> > > caRegionName = get(handles.edtRegion1, 'string');
> >
> > > When I check strRegionName and caRegionName in the workspace, guess
> > > what?
> > > It says they're both 1 by 1 cell arrays.
> > > -ImageAnalyst
> >
> > that's terrifying. and would make quite a few of my guis bad. just for
> > example string concatenation,
> >
> > strRegionName = get(hObject,'String');
> > strFull = [strRegionName '_please let me be one string']
> >
> > would give a 1x2 cell, not a complete string. surely it's a bug?
> >
> > -qooroo-
>
> ------------------------------------------------------------------------------------------------------------------------------------------
> Even the Mathworks tech support folks were surprised. They're the
> ones who told me to use iscell() workaround to check so that it would
> work for any version. I'll send it in as a bug report. But with my
> license lasting only about 20 days, the new release is about to come
> out within that time I imagine, so I'm not sure it will make it in if
> they don't already know about it. I notified them of another bug a
> couple of weeks ago and they said that they couldn't fix it in time.

If by "the new release" you mean release R2009b, it's already out; it was
released last Friday.

http://www.mathworks.com/products/new_products/latest_features.html

If by "the new release" you mean release R2010a, it's due out sometime in
the spring.

> What you said was right (I think Chris misunderstood). I ran your
> code in R2009b and verfied that it is, in fact, a 1 by 2 cell and you
> do not have one long string. I am not sure why they decided to make
> this change. Unless they fix this, you'll be implementing the
> workaround like I did to have your old m-files run in the new
> version. Maybe Steve Lord has some inside info on this????
> -ImageAnalyst

I believe the concatenation behavior is is related to a change we made a
while back related to the behavior of concatenation with cell arrays and
numeric arrays. In older releases (I forget exactly when we made this
change) this code would error:

x = [{1 2 3} 1e4]

because this was treated as:

x = [{1 2 3} cell(1e4)]

which would try to create a 1e4-by-1e4 cell array and combine it with a
1-by-3 cell array. What we believed most users would expect was a 4-element
cell array whose fourth cell was {1e4}:

x = [{1 2 3} {1e4}] % or x = {1 2 3 1e4}

and that's what it currently does.

As for the uicontrol behavior you're seeing, I did a quick search (because
this didn't sound familiar) and I think you may be experiencing the problem
described in bug report 250127:

http://www.mathworks.com/support/bugreports/250127

If you're still communicating with Technical Support about this issue, ask
them to speak to the developers working on that bug report.

--
Steve Lord
slord@mathworks.com
comp.soft-sys.matlab (CSSM) FAQ: http://matlabwiki.mathworks.com/MATLAB_FAQ