FROM : John Stiles
DATE : Thu Mar 06 18:59:33 2008
On Leopard, this solution works perfectly. I get a chance to update my
view right before it draws, which is exactly what the doctor ordered.
Any way to get this on Tiger or am I just out of luck?
John Stiles wrote:
> 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:59:33 2008
On Leopard, this solution works perfectly. I get a chance to update my
view right before it draws, which is exactly what the doctor ordered.
Any way to get this on Tiger or am I just out of luck?
John Stiles wrote:
> 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

