FROM : John Stiles
DATE : Sat Jan 05 01:27:31 2008
Actually, I'd like to point out what appears to be another, more subtle
bug in this example code.
It uses "-init" to initialize the custom field editor—however, custom
field editors should almost certainly be subclasses of NSText, and so
they should use the designated initializer "-initWithFrame:". Right?
John Stiles wrote:
> Cool, thanks for filing it on my behalf :)
> I had been running under the assumption that the sample snippet was
> too simple, so fortunately the code I just wrote is not bogus… thanks!
>
>
> Aki Inoue wrote:
>> Yes, admittedly, the sample code is probably too simplified.
>>
>> Usually you should store your custom field editor instance somewhere
>> and have mapping mechanism between the editor and window/object.
>>
>> Also, another issue with this sample is that it's returning the
>> custom editor for all NSTextField subclasses and could cause issues
>> if there is an NSTextField subclass that already requires its own
>> NSTextView subclass.
>>
>> It should selectively return the custom field editor.
>>
>> I filed a bug 5670642 for requesting tech document improvement.
>>
>> Thanks,
>> Aki
>>
>> On 2008/01/04, at 11:35, John Stiles wrote:
>>
>>> I'm looking at creating a custom field editor (so I can filter out
>>> keystrokes in various types of controls in a consistent way).
>>> The text editing programming guide has a section called "How to
>>> Substitute a Custom Field Editor", with an example snippet which
>>> seems nice and simple:
>>>
>>>> (id)windowWillReturnFieldEditor:(NSWindow *)sender
>>>> toObject:(id)anObject
>>>> {
>>>> if ([anObject isKindOfClass:[NSTextField class]])
>>>> {
>>>> return [[[myCustomFieldEditor alloc] init] autorelease];
>>>> }
>>>> return nil;
>>>> }
>>>
>>>
>>> (Admittedly, there are two problems in the code—no leading hyphen
>>> and a lowercase class name—but I'm going to let that slide for now :) )
>>> However, according to the docs for
>>> -windowWillReturnFieldEditor:toObject:, this code is actually broken:
>>>
>>>> Discussion
>>>> This method may be called multiple times while a control is first
>>>> responder. Therefore, you must return the same field editor object
>>>> for the control while the control is being edited.
>>>
>>> This seems to directly contradict the sample code above, so which is
>>> correct? I'll happily file it, but I just wanted to run this past
>>> someone who might have already been down this road before.
>>> _______________________________________________
>>>
>>> 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 : Sat Jan 05 01:27:31 2008
Actually, I'd like to point out what appears to be another, more subtle
bug in this example code.
It uses "-init" to initialize the custom field editor—however, custom
field editors should almost certainly be subclasses of NSText, and so
they should use the designated initializer "-initWithFrame:". Right?
John Stiles wrote:
> Cool, thanks for filing it on my behalf :)
> I had been running under the assumption that the sample snippet was
> too simple, so fortunately the code I just wrote is not bogus… thanks!
>
>
> Aki Inoue wrote:
>> Yes, admittedly, the sample code is probably too simplified.
>>
>> Usually you should store your custom field editor instance somewhere
>> and have mapping mechanism between the editor and window/object.
>>
>> Also, another issue with this sample is that it's returning the
>> custom editor for all NSTextField subclasses and could cause issues
>> if there is an NSTextField subclass that already requires its own
>> NSTextView subclass.
>>
>> It should selectively return the custom field editor.
>>
>> I filed a bug 5670642 for requesting tech document improvement.
>>
>> Thanks,
>> Aki
>>
>> On 2008/01/04, at 11:35, John Stiles wrote:
>>
>>> I'm looking at creating a custom field editor (so I can filter out
>>> keystrokes in various types of controls in a consistent way).
>>> The text editing programming guide has a section called "How to
>>> Substitute a Custom Field Editor", with an example snippet which
>>> seems nice and simple:
>>>
>>>> (id)windowWillReturnFieldEditor:(NSWindow *)sender
>>>> toObject:(id)anObject
>>>> {
>>>> if ([anObject isKindOfClass:[NSTextField class]])
>>>> {
>>>> return [[[myCustomFieldEditor alloc] init] autorelease];
>>>> }
>>>> return nil;
>>>> }
>>>
>>>
>>> (Admittedly, there are two problems in the code—no leading hyphen
>>> and a lowercase class name—but I'm going to let that slide for now :) )
>>> However, according to the docs for
>>> -windowWillReturnFieldEditor:toObject:, this code is actually broken:
>>>
>>>> Discussion
>>>> This method may be called multiple times while a control is first
>>>> responder. Therefore, you must return the same field editor object
>>>> for the control while the control is being edited.
>>>
>>> This seems to directly contradict the sample code above, so which is
>>> correct? I'll happily file it, but I just wanted to run this past
>>> someone who might have already been down this road before.
>>> _______________________________________________
>>>
>>> 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 |
|---|---|---|
| John Stiles | Jan 4, 20:35 | |
| Aki Inoue | Jan 4, 20:54 | |
| John Stiles | Jan 4, 21:02 | |
| John Stiles | Jan 5, 01:27 | |
| Ken Ferry | Jan 8, 09:31 | |
| John Stiles | Jan 8, 18:56 |






Cocoa mail archive

