FROM : Aki Inoue
DATE : Wed Feb 13 23:56:43 2008
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
> <email_removed>
> http://www.noodlesoft.com
>
> _______________________________________________
>
> Cocoa-dev mailing list (<email_removed>)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/<email_removed>
>
> This email sent to <email_removed>
DATE : Wed Feb 13 23:56:43 2008
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
> <email_removed>
> http://www.noodlesoft.com
>
> _______________________________________________
>
> Cocoa-dev mailing list (<email_removed>)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/<email_removed>
>
> This email sent to <email_removed>
| Related mails | Author | Date |
|---|---|---|
| Paul Kim | Feb 13, 20:43 | |
| Jim Correia | Feb 13, 21:49 | |
| Paul Kim | Feb 13, 22:10 | |
| Jim Correia | Feb 13, 22:36 | |
| Paul Kim | Feb 13, 23:30 | |
| Aki Inoue | Feb 13, 23:56 | |
| Paul Kim | Feb 14, 00:21 | |
| Aki Inoue | Feb 14, 00:26 |






Cocoa mail archive

