FROM : John Stiles
DATE : Thu Mar 06 18:33:08 2008
Oh, wait… this requires Leopard :|
Is there anything that works with Tiger? I'm trying to avoid Leopard
dependencies when there are easy substitutes.
John Stiles wrote:
> Actually, in this case, it seems like a perfect fit for what I'm
> doing. I'm already using a subclassed view anyway. I will definitely
> take a look at -viewWillDraw:.
>
> BTW, views don't actually have delegates—many control subclasses do,
> e.g. NSTableView has one—but a plain NSView does not.
>
> Thanks, Ken! I'll let you know if this resolves my issue. I highly
> suspect that it will.
>
> j o a r wrote:
>>
>> On Mar 6, 2008, at 8:32 AM, Ken Ferry wrote:
>>
>>> Or can you do your final setup in -viewWillDraw?
>>>
>>> For some kinds of problems, you could synchronously mark whatever
>>> state you're interested as invalid, then resolve any invalidated
>>> state in -viewWillDraw. This would be an appropriate way to do
>>> deferred layout, for example.
>>
>>
>> I think it's unfortunate to have to resolve to subclassing for this
>> type of problem - The OP might end up having to subclass several
>> different NSControl subclasses to make it work. Perhaps NSView should
>> provide some sort of notification or delegation scheme to supplement
>> this method?
>>
>> j o a r
>>
>>
>> _______________________________________________
>>
>> 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>
> _______________________________________________
>
> 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 : Thu Mar 06 18:33:08 2008
Oh, wait… this requires Leopard :|
Is there anything that works with Tiger? I'm trying to avoid Leopard
dependencies when there are easy substitutes.
John Stiles wrote:
> Actually, in this case, it seems like a perfect fit for what I'm
> doing. I'm already using a subclassed view anyway. I will definitely
> take a look at -viewWillDraw:.
>
> BTW, views don't actually have delegates—many control subclasses do,
> e.g. NSTableView has one—but a plain NSView does not.
>
> Thanks, Ken! I'll let you know if this resolves my issue. I highly
> suspect that it will.
>
> j o a r wrote:
>>
>> On Mar 6, 2008, at 8:32 AM, Ken Ferry wrote:
>>
>>> Or can you do your final setup in -viewWillDraw?
>>>
>>> For some kinds of problems, you could synchronously mark whatever
>>> state you're interested as invalid, then resolve any invalidated
>>> state in -viewWillDraw. This would be an appropriate way to do
>>> deferred layout, for example.
>>
>>
>> I think it's unfortunate to have to resolve to subclassing for this
>> type of problem - The OP might end up having to subclass several
>> different NSControl subclasses to make it work. Perhaps NSView should
>> provide some sort of notification or delegation scheme to supplement
>> this method?
>>
>> j o a r
>>
>>
>> _______________________________________________
>>
>> 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>
> _______________________________________________
>
> 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>






Cocoa mail archive

