Let me try character-art to illustrate the issue (forgive the top-post):
+-----------+
Title: | | <= splits on spaces only, counts dups
+-----------+
Label: word count Label:dup count
+-----------+
Keywords: | | <= splits on comma with optional
+-----------+ whitespace, counts dups
Label: word count Label:dup count
NSTextField
|
DuplicateCounterTextField
So, in IB, I set the class of the two fields to DuplicateCounterTextField
and the delegate to WindowController. DuplicateCounterTextField implements:
- textDidChange:notification;
- textView:view completions:completions
forPartialWordRange:range
indexOfSelectedItem:index
In the delegate class's awakeFromNib, I set the splitter string, which works
fine.
So, WindowController understands that there is an outlet called title and one
called keywords, and that they are connected to the corresponding controls on
the form. However, DuplicateCounterTextField is deliberately stupid. The
question is, should an instance of DuplicateCounterTextField call a (to be
implemented) delegate method wordCountDidChange:notification to allow the
two labels to be updated by WindowController, thus tying the whole thing
together or is there a better way.
Clearly, this is a trivial example, but I'm trying to understand desirable
patterns that can last as an application grows.
Thanks,
Steve
On Nov 14, 2009, at 5:41 AM, Jerry Krinock wrote:
>
> On 2009 Nov 12, at 18:54, s.ross wrote:
>
>> That suggests to me that subclassing NSTextField and allowing a single
>> controller to register a callback would be the right way to go, but I'm
>> struggling with how to specify *which* text field
>
> I don't understand the question. You subclass class definitions, not
> instances. The thing you would subclass would be NSTextField. Your subclass
> will be a "sister" of, for example, NSSecureTextField.
>
>> and whether my design idea is even sound.
>
> other than that, it looks like you know what you are doing.
>
> _______________________________________________
>
_______________________________________________
Cocoa-dev mailing list ([email protected])
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/archive%40mail-archive.com
This email sent to [email protected]
