Garbage in button title

[Eric VERGNAUD]

Hi,

A little more experienced than a few hours ago :-).

I'm trying to programmatically set the title of a button, using the
following:

[inRef setTitle:[NSString stringWithCString:@"Hello"]];

However, this end up with the button displaying garbage.

I noticed the same problem when using SetControlTitleWithCFString in Carbon,
so I switched back to SetControlTitle, which is ok, but I cannot use this
trick in Cocoa.

Is this a known problem, or is there omething wrong in the code above ?

Thanks,

Eric

[Frederick Cheung]

On Sat, 13 Sep 2003, Eric VERGNAUD wrote:

> Hi,
>
> A little more experienced than a few hours ago :-).
>
> I'm trying to programmatically set the title of a button, using the
> following:
>
> [inRef setTitle:[NSString stringWithCString:@"Hello"]];
>
> However, this end up with the button displaying garbage.
>
> I noticed the same problem when using SetControlTitleWithCFString in Carbon,
> so I switched back to SetControlTitle, which is ok, but I cannot use this
> trick in Cocoa.
>
> Is this a known problem, or is there omething wrong in the code above ?

Yes. @"Hello" is already a NSString. A plain old C string constant would
be written without the @ (and in carbon
SetControlTitleWithCFString(theControl,CFSTR("My title")); will work)

Fred

[Eric VERGNAUD]

dans l'article
[email]Pine.LNX.4.44.0309122307180.8789-100000@kern.srcf.societies.cam.ac.uk[/email],
Frederick Cheung à [email]fglc2@srcf.DUH.ucam.org[/email] a écrit le 13/09/03 0:09*:

> On Sat, 13 Sep 2003, Eric VERGNAUD wrote:
>

>> Hi,
>>
>> A little more experienced than a few hours ago :-).
>>
>> I'm trying to programmatically set the title of a button, using the
>> following:
>>
>> [inRef setTitle:[NSString stringWithCString:@"Hello"]];
>>
>> However, this end up with the button displaying garbage.
>>
>> I noticed the same problem when using SetControlTitleWithCFString in Carbon,
>> so I switched back to SetControlTitle, which is ok, but I cannot use this
>> trick in Cocoa.
>>
>> Is this a known problem, or is there omething wrong in the code above ?

>
> Yes. @"Hello" is already a NSString. A plain old C string constant would
> be written without the @ (and in carbon
> SetControlTitleWithCFString(theControl,CFSTR("My title")); will work)
>
> Fred
>

Thank you Fred,

In fact, I've been going a little further and found that:

[inRef setTitle:@"Hello"];

Works perfectly.

However, what I was looking for in the first place, is to set the button
title with a string passed as a parameter, like in:

void CocoaSetControlCaption(NSButton* inRef,NSString* inString)
{
[inRef setTitle: inString];
}

That didn't work.

The reason is that setTitle does NOT retain the string. So when the caller
does, the NSString held by the NSButton is no longer valid.

So finally, I changed my code to:

[inRef setTitle: [NSString stringWithString:inString]];

And that does it, because now the button owns the title.

Thanks,

Eric

[matt neuburg]

In <BB8819D8.11FA9%eric.vergnaud@wanadoo.fr> Eric VERGNAUD wrote:

> However, what I was looking for in the first place, is to set the
> button title with a string passed as a parameter, like in:
>
> void CocoaSetControlCaption(NSButton* inRef,NSString* inString)
> {
> [inRef setTitle: inString];
>}
>
> That didn't work.
>
> The reason is that setTitle does NOT retain the string.

Certainly it does. If it didn't, this next code would not work:

> So finally, I changed my code to:
> [inRef setTitle: [NSString stringWithString:inString]];

The output of stringWithString is autoreleased, and you are not
retaining it, so if setTitle didn't retain it, the title would vanish in
a puff of smoke. This proves that setTitle *does* retain the string.

What was wrong with your original code was exactly what you were told by
Frederick Cheung - you were supplying an NSString where a C string was
expected. m.

PS stringWithCString is deprecated so don't use it. The reason is that
it gives you no control over the encoding.

--
matt neuburg, phd = [email]matt@tidbits.com[/email], [url]http://www.tidbits.com/matt[/url]
REALbasic: The Definitive Guide! 2nd edition!
[url]http://www.amazon.com/exec/obidos/ASIN/0596001770/somethingsbymatt[/url]
Subscribe to TidBITS. It's free and smart.

[Manfred Lippert]

> However, what I was looking for in the first place, is to set the button

> title with a string passed as a parameter, like in:
>
> void CocoaSetControlCaption(NSButton* inRef,NSString* inString)
> {
> [inRef setTitle: inString];
> }
>
> That didn't work.
>
> The reason is that setTitle does NOT retain the string. So when the caller
> does, the NSString held by the NSButton is no longer valid.

No, I don't think so. I don't know what is going wrong in your code, but
your last sentence can not be true. It would make not any sense if Cocoa
would not retain the NSString in setTitle, I can not believe this.
It must be some other reason why your code failed.

> So finally, I changed my code to:
>
> [inRef setTitle: [NSString stringWithString:inString]];
>
> And that does it, because now the button owns the title.

No, this could not be the solution, if really setTitle does not retain the
string. You have the same situation as before. Because: with [NSString
stringWithString:inString] the actual autorelease pool is owning the string
(not the button) and so you should have the same problem as before. The
string passed to setTitle will be released soon, and if setTitle would
really not retain it (what I can not believe) then your button would have
the same problem as before.

Regards,
Mani
---
iVolume, LittleSecrets, SharingMenu:
[url]http://www.mani.de/[/url]

[Eric VERGNAUD]

dans l'article BB891758.19A58%mani@mani.de, Manfred Lippert à [email]mani@mani.de[/email] a
écrit le 13/09/03 18:50*:

>> However, what I was looking for in the first place, is to set the button
>> title with a string passed as a parameter, like in:
>>
>> void CocoaSetControlCaption(NSButton* inRef,NSString* inString)
>> {
>> [inRef setTitle: inString];
>> }
>>
>> That didn't work.
>>
>> The reason is that setTitle does NOT retain the string. So when the caller
>> does, the NSString held by the NSButton is no longer valid.

>
> No, I don't think so. I don't know what is going wrong in your code, but
> your last sentence can not be true. It would make not any sense if Cocoa
> would not retain the NSString in setTitle, I can not believe this.
> It must be some other reason why your code failed.
>

>> So finally, I changed my code to:
>>
>> [inRef setTitle: [NSString stringWithString:inString]];
>>
>> And that does it, because now the button owns the title.

>
> No, this could not be the solution, if really setTitle does not retain the
> string. You have the same situation as before. Because: with [NSString
> stringWithString:inString] the actual autorelease pool is owning the string
> (not the button) and so you should have the same problem as before. The
> string passed to setTitle will be released soon, and if setTitle would
> really not retain it (what I can not believe) then your button would have
> the same problem as before.

Well maybe it COULD not be, but it IS.

This is probably related to some unknown inners of NSString. The NSString I
was passing to the above routine was referring to some UniCode data held in
a Mac handle being disposed immediatly after return:

Void MySetCaption(NSButtonRef inRef,char* inCString)
{
MyOwnUnicodeString str(inCString);
MyMacCFStringFactory cfstr(str); // locks the Unicode data in str and
provides a temporary CFString

CocoaSetControlCaption(inRef,cfstr.GetCFString());

// the destructor of cfstr
// releases the CFString
// unlocks the data

// the destructor of str
// dispose the unicode data
}

I agree that setTitle retains the string. However, it accepts a CFString
which does not own its data without making a copy. That was the reason of my
trouble.

Thanks anyway.


Eric

[Michael J Ash]

On Sat, 13 Sep 2003, Eric VERGNAUD wrote:

> Well maybe it COULD not be, but it IS.
>
> This is probably related to some unknown inners of NSString. The NSString I
> was passing to the above routine was referring to some UniCode data held in
> a Mac handle being disposed immediatly after return:

You're creating some weird fake CFString instance that does not follow the
rules of reference counting. Rules such as, an object should remain valid
until its reference count reaches zero. One shouldn't be required to make
a copy, a simple retain should be sufficient. Your fake instance broke
those rules and so of course it produced incorrect results.

> I agree that setTitle retains the string. However, it accepts a CFString
> which does not own its data without making a copy. That was the reason of my
> trouble.

You can't do this and expect it to work. If a CFString doesn't own its
data then it can't follow the semantics that the frameworks and everyone
else expect them to follow, so you get broken code.

--
"From now on, we live in a world where man has walked on the moon.
And it's not a miracle, we just decided to go." -- Jim Lovell

Mike Ash - <http://www.mikeash.com/>, <mailto:mail@mikeash.com>

[Miro Jurisic]

In article <Pine.OSF.3.96.1030913131008.14915A-100000@alpha3.csd.uwm.edu>,
Michael J Ash <mikeash@csd.uwm.edu> wrote:

> You can't do this and expect it to work. If a CFString doesn't own its
> data then it can't follow the semantics that the frameworks and everyone
> else expect them to follow, so you get broken code.

That's not true. Look at CFStringCreateWith*StringNoCopy.

meeroh

--
If this message helped you, consider buying an item
from my wish list: <http://web.meeroh.org/wishlist>

[Frederick Cheung]

On Sat, 13 Sep 2003, Miro Jurisic wrote:

> In article <Pine.OSF.3.96.1030913131008.14915A-100000@alpha3.csd.uwm.edu>,
> Michael J Ash <mikeash@csd.uwm.edu> wrote:
>

> > You can't do this and expect it to work. If a CFString doesn't own its
> > data then it can't follow the semantics that the frameworks and everyone
> > else expect them to follow, so you get broken code.

>
> That's not true. Look at CFStringCreateWith*StringNoCopy.

Although strings created thusly don't work with DrawThemeTextBox and some
of its friends.

Fred

[Miro Jurisic]

In article
<Pine.LNX.4.44.0309132109020.20310-100000@kern.srcf.societies.cam.ac.uk>,
Frederick Cheung <fglc2@srcf.DUH.ucam.org> wrote:

> On Sat, 13 Sep 2003, Miro Jurisic wrote:
>

> > In article <Pine.OSF.3.96.1030913131008.14915A-100000@alpha3.csd.uwm.edu>,
> > Michael J Ash <mikeash@csd.uwm.edu> wrote:
> >

> > > You can't do this and expect it to work. If a CFString doesn't own its
> > > data then it can't follow the semantics that the frameworks and everyone
> > > else expect them to follow, so you get broken code.

> >
> > That's not true. Look at CFStringCreateWith*StringNoCopy.

> Although strings created thusly don't work with DrawThemeTextBox and some
> of its friends.

Sure they do. You just can't let the buffer go away before the text box is done
with it.

meeroh

--
If this message helped you, consider buying an item
from my wish list: <http://web.meeroh.org/wishlist>

[Frederick Cheung]

On Sat, 13 Sep 2003, Miro Jurisic wrote:

> In article
> <Pine.LNX.4.44.0309132109020.20310-100000@kern.srcf.societies.cam.ac.uk>,
> Frederick Cheung <fglc2@srcf.DUH.ucam.org> wrote:
>

> > On Sat, 13 Sep 2003, Miro Jurisic wrote:
> >

> > > In article <Pine.OSF.3.96.1030913131008.14915A-100000@alpha3.csd.uwm.edu>,
> > > Michael J Ash <mikeash@csd.uwm.edu> wrote:
> > >
> > > > You can't do this and expect it to work. If a CFString doesn't own its
> > > > data then it can't follow the semantics that the frameworks and everyone
> > > > else expect them to follow, so you get broken code.
> > >
> > > That's not true. Look at CFStringCreateWith*StringNoCopy.

> > Although strings created thusly don't work with DrawThemeTextBox and some
> > of its friends.

>
> Sure they do. You just can't let the buffer go away before the text box is done
> with it.

Hmm. It explicitly says not to do this in the headers.

Fred

[Eric VERGNAUD]

dans l'article [email]macdev-1ACB91.14354713092003@senator-bedfellow.mit.edu[/email], Miro
Jurisic à [email]macdev@meeroh.org[/email] a écrit le 13/09/03 20:35*:

> In article <Pine.OSF.3.96.1030913131008.14915A-100000@alpha3.csd.uwm.edu>,
> Michael J Ash <mikeash@csd.uwm.edu> wrote:
>

>> You can't do this and expect it to work. If a CFString doesn't own its
>> data then it can't follow the semantics that the frameworks and everyone
>> else expect them to follow, so you get broken code.

>
> That's not true. Look at CFStringCreateWith*StringNoCopy.
>
> meeroh

Which, by the way, is what I was using in my example. I was expecting the OS
to be AWARE of the fact that the NSString did not own its data, and would
cleverly make a copy of it.

Or more frankly, I had no clue, but now that the problem is solved, I think
it's what it should do.

Eric