NSTokenField bug in 10.5.2?
-
Hi all,
It appears the behavior of NSTokenField has changed in 10.5.2. It now
trims any space around any tokens. This includes plain style tokens
(which look just like regular strings). This behavior is quite
undesirable in my shipping app and I have heard reports that it is
adversely affecting other apps as well.
I'm having problems figuring out a workaround as every delegate/
notification method already has the spaces trimmed off before I can
get to them. My guess is that it's being done at the field editor. So,
does anyone know of a workaround? Note that the tokenizing character
set is set to empty so whitespace characters do not tokenize.
Actually, nothing is tokenized in the field; all tokens are dragged in
from outside the field. And just to be clear, this all worked fine on
10.5.1 and before.
Also, for you apple folks, I've filed this as rdar://5739172
Thanks in advance,
Paul Kim -
On Feb 13, 2008, at 2:43 PM, Paul Kim wrote:
> It appears the behavior of NSTokenField has changed in 10.5.2. It
> now trims any space around any tokens. This includes plain style
> tokens (which look just like regular strings).
Are you linking against the 10.4 or 10.5 SDK?
I previously ran into the reverse problem NSTokenField automatically
trimmed trailling and leading whitespace in 10.4, so I was surprised
to see the spaces appear in 10.5. (And it did represent a binary
compatibility problem for my application.)
I've since implemented the appropriate delegate methods to ensure the
trimming happens if necessary.
> I'm having problems figuring out a workaround as every delegate/
> notification method already has the spaces trimmed off before I can
> get to them.
It appears as though the previous behavior (trimming whitespace) may
have been restored using a linked-on-or-after test. My delegate gets
trimmed strings if I link against the 10.4 SDK, untrimmed strings if I
link against the 10.5 SDK.
Maybe someone from Apple can confirm this.
This behavior preserves binary compatibility with apps written for
10.4 which expected to get the trimmed strings since that is all they
were ever sent.
If you support 10.4 you must plan on getting trimmed strings, because
that was always the behavior.
If possible, link against the 10.5 SDK, since that seems to get you
the behavior you desire on Leopard.
Jim -
Hi Jim,
I'm currently linking against 10.5 though this app runs on Tiger and
has been for some time. I don't recall seeing any differences in
behavior on this front between 10.4 and 10.5 (up to 10.5.1). I am
running my test program right now linked against the 10.4 SDK on
10.4.11, 10.5.1 and 10.5.2 and 10.5.2 is the odd man out. Switching to
the 10.5 SDK, I'm seeing the same behavior (of course, only on the
10.5 machines).
You can download my cobbled together test here: http://www.noodlesoft.com/beta/TokenFieldExample.zip
To demonstrate the problem, in the token field, type a space then some
characters. Hit tab to shift focus somewhere else. On 10.5.2, the
first space will disappear. You can also drag in a token, type a space
and some characters and the space will disappear when the field loses
focus.
This is crippling the UI for a couple key features of my app. At least
if you don't automatically trim the spaces, you can do it manually
after the fact. Unfortunately, putting it back is not so easy since
you have no idea what whitespace characters were typed in.
What I'd like to know is what voodoo the date/time format editor in
SysPrefs is using to avoid this.
Paul Kim
On Feb 13, 2008, at 3:49 PM, Jim Correia wrote:
> On Feb 13, 2008, at 2:43 PM, Paul Kim wrote:
>
>> It appears the behavior of NSTokenField has changed in 10.5.2. It
>> now trims any space around any tokens. This includes plain style
>> tokens (which look just like regular strings).
>
> Are you linking against the 10.4 or 10.5 SDK?
>
> I previously ran into the reverse problem NSTokenField automatically
> trimmed trailling and leading whitespace in 10.4, so I was surprised
> to see the spaces appear in 10.5. (And it did represent a binary
> compatibility problem for my application.)
>
> I've since implemented the appropriate delegate methods to ensure
> the trimming happens if necessary.
>
>> I'm having problems figuring out a workaround as every delegate/
>> notification method already has the spaces trimmed off before I can
>> get to them.
>
> It appears as though the previous behavior (trimming whitespace) may
> have been restored using a linked-on-or-after test. My delegate gets
> trimmed strings if I link against the 10.4 SDK, untrimmed strings if
> I link against the 10.5 SDK.
>
> Maybe someone from Apple can confirm this.
>
> This behavior preserves binary compatibility with apps written for
> 10.4 which expected to get the trimmed strings since that is all
> they were ever sent.
>
> If you support 10.4 you must plan on getting trimmed strings,
> because that was always the behavior.
>
> If possible, link against the 10.5 SDK, since that seems to get you
> the behavior you desire on Leopard.
>
> Jim
-
On Feb 13, 2008, at 4:10 PM, Paul Kim wrote:
> I'm currently linking against 10.5 though this app runs on Tiger and
> has been for some time. I don't recall seeing any differences in
> behavior on this front between 10.4 and 10.5 (up to 10.5.1). I am
> running my test program right now linked against the 10.4 SDK on
> 10.4.11, 10.5.1 and 10.5.2 and 10.5.2 is the odd man out. Switching
> to the 10.5 SDK, I'm seeing the same behavior (of course, only on
> the 10.5 machines).
When my app was linked against the 10.4 SDK (and always when running
on 10.4), I always got trimmed token values. On 10.5.0-1 I didn't. But
I'm not using the token field the same way you are. I'm using the blue
appearance tokens, and have the field wired up through bindings.
Playing with your app as is, but changing the token style to the
rounded style seems to also avoid the problem. (Which I understand may
not be practical depending on your usage.)
I just hacked together a test in my shipping app, and when I link
against the 10.4 SDK on 10.5.2, I get the old behavior where the
strings are trimmed. Linking against the 10.5 SDK, I get the trimless
behavior. (See below.)
> You can download my cobbled together test here: http://www.noodlesoft.com/beta/TokenFieldExample.zip
>
> To demonstrate the problem, in the token field, type a space then
> some characters. Hit tab to shift focus somewhere else. On 10.5.2,
> the first space will disappear. You can also drag in a token, type a
> space and some characters and the space will disappear when the
> field loses focus.
Your example is currently targeting the 10.4 SDK. If you re-target
10.5, and then supply this no-op delegate method, the spaces appear to
be preserved.
- (id)tokenField:(NSTokenField *)tokenField
representedObjectForEditingString:(NSString *)editingString;
{
NSLog(@"Editing string = \"%@\"", editingString);
return editingString;
}
> This is crippling the UI for a couple key features of my app. At
> least if you don't automatically trim the spaces, you can do it
> manually after the fact. Unfortunately, putting it back is not so
> easy since you have no idea what whitespace characters were typed in.
In the abstract, I agree. (This was in fact the reasoning Apple
engineering gave for the original change, which ended up being a
binary compatibility problem for previous versions of my application.
The current version does the right thing.)
Jim -
On Feb 13, 2008, at 4:36 PM, Jim Correia wrote:
>
> Playing with your app as is, but changing the token style to the
> rounded style seems to also avoid the problem. (Which I understand
> may not be practical depending on your usage.)
I'm actually using a combination of the plain and rounded ones. It's
just that the rounded ones don't get created by typing, but have to be
dragged in from the non-editable token fields below (like a palette).
The appearance to the user is text with tokens embedded within in.
>
> Your example is currently targeting the 10.4 SDK. If you re-target
> 10.5, and then supply this no-op delegate method, the spaces appear
> to be preserved.
>
> - (id)tokenField:(NSTokenField *)tokenField
> representedObjectForEditingString:(NSString *)editingString;
> {
> NSLog(@"Editing string = \"%@\"", editingString);
> return editingString;
> }
That seems to do the trick (still testing it on different versions).
Technically, I guess it's not a no-op since omitting the method does
change its behavior. You'd think this would be the default behavior if
your delegate doesn't implement the method. Many thanks (and beers if/
when we cross paths)!
My issue with NSTokenField is not so much the specific problems but
the fact that the problems keep shifting and it's a bit tiring keeping
up with the workarounds.
Thanks again,
Paul Kim
------------------------------------
Chief Noodler - Noodlesoft
<mr_noodle...>
http://www.noodlesoft.com -
It appears the ML figured it out.
Yes, we did trim whitespace in 10.4, and the behavior change in 10.5
caused binary compatibility problems with various applications.
We rolled out a solution for the binary compatibility problem in 10.5.2.
The logic to determine whether or not to apply the auto whitespace
trimming is:
- trims if linked against 10.4.x binary
- trims if linked against 10.5.x binary and the delegate doesn't
implement -tokenField:representedObjectForEditingString:
- does not trims if linked against 10.5.x binary and the delegate
implements -tokenField:representedObjectForEditingString:
Aki
On 2008/02/13, at 14:30, Paul Kim wrote:
> On Feb 13, 2008, at 4:36 PM, Jim Correia wrote:
>>
>> Playing with your app as is, but changing the token style to the
>> rounded style seems to also avoid the problem. (Which I understand
>> may not be practical depending on your usage.)
>
>
> I'm actually using a combination of the plain and rounded ones. It's
> just that the rounded ones don't get created by typing, but have to
> be dragged in from the non-editable token fields below (like a
> palette). The appearance to the user is text with tokens embedded
> within in.
>
>>
>> Your example is currently targeting the 10.4 SDK. If you re-target
>> 10.5, and then supply this no-op delegate method, the spaces appear
>> to be preserved.
>>
>> - (id)tokenField:(NSTokenField *)tokenField
>> representedObjectForEditingString:(NSString *)editingString;
>> {
>> NSLog(@"Editing string = \"%@\"", editingString);
>> return editingString;
>> }
>
>
> That seems to do the trick (still testing it on different versions).
> Technically, I guess it's not a no-op since omitting the method does
> change its behavior. You'd think this would be the default behavior
> if your delegate doesn't implement the method. Many thanks (and
> beers if/when we cross paths)!
>
> My issue with NSTokenField is not so much the specific problems but
> the fact that the problems keep shifting and it's a bit tiring
> keeping up with the workarounds.
>
> Thanks again,
>
> Paul Kim
> ------------------------------------
> Chief Noodler - Noodlesoft
> <mr_noodle...>
> http://www.noodlesoft.com
-
On Feb 13, 2008, at 5:56 PM, Aki Inoue wrote:
> It appears the ML figured it out.
>
> Yes, we did trim whitespace in 10.4, and the behavior change in 10.5
> caused binary compatibility problems with various applications.
>
> We rolled out a solution for the binary compatibility problem in
> 10.5.2.
> The logic to determine whether or not to apply the auto whitespace
> trimming is:
> - trims if linked against 10.4.x binary
> - trims if linked against 10.5.x binary and the delegate doesn't
> implement -tokenField:representedObjectForEditingString:
> - does not trims if linked against 10.5.x binary and the delegate
> implements -tokenField:representedObjectForEditingString:
>
> Aki
Thanks for the definitive statement on this. Will the docs be updated
to explain this? Should I file a radar for it (or update the existing
one)?
Paul Kim -
> Thanks for the definitive statement on this. Will the docs bePlease file a bug for doc update.
> updated to explain this? Should I file a radar for it (or update the
> existing one)?
Thanks,
Aki
On 2008/02/13, at 15:21, Paul Kim wrote:
> On Feb 13, 2008, at 5:56 PM, Aki Inoue wrote:
>
>> It appears the ML figured it out.
>>
>> Yes, we did trim whitespace in 10.4, and the behavior change in
>> 10.5 caused binary compatibility problems with various applications.
>>
>> We rolled out a solution for the binary compatibility problem in
>> 10.5.2.
>> The logic to determine whether or not to apply the auto whitespace
>> trimming is:
>> - trims if linked against 10.4.x binary
>> - trims if linked against 10.5.x binary and the delegate doesn't
>> implement -tokenField:representedObjectForEditingString:
>> - does not trims if linked against 10.5.x binary and the delegate
>> implements -tokenField:representedObjectForEditingString:
>>
>> Aki
>
> Thanks for the definitive statement on this. Will the docs be
> updated to explain this? Should I file a radar for it (or update the
> existing one)?
>
> Paul Kim
