Re: Live resizing strategies for custom views
Re: Live resizing strategies for custom views
- Subject: Re: Live resizing strategies for custom views
- From: jkp <email@hidden>
- Date: Wed, 5 Oct 2005 11:13:48 +0100
Cameron -
This was the approach i used elsewhere in my app when i needed to
throttle calls to a routine - im not quite sure if it would work with
views in this way since you need to call drawRect in some way to
display _something_ of the correct size. I cant see any real way of
doing this properly without subclassing (or modifiying) the
containers so that they send some message to the subviews when a
resize is going to happen.
I like your routine anyway tho - more generic than the way i
implemented it - ill use that if its ok!
Cheers
Jamie
On 5 Oct 2005, at 10:53, Cameron Hayne wrote:
On 5-Oct-05, at 5:04 AM, jkp wrote:
This functionality is great and really helps when you have complex
views that dont cope with redrawing very fast, but it doesnt cover
off other "liveResizing" type situations such as when a view is
enclosed in a splitView (in this case an RBSplitView). There is
no way to query whether or not a live resize is happening in this
or any other situation.
I'm looking for a method to allow me to tell if my view is being
resized generally - so that i could implement alternative drawing
routines in these situaitons.
1) Maybe you should submit a bug report requesting that the
"LiveResize" methods should be triggered in these situations as well.
2) You could watch for NSViewFrameDidChangeNotification
notifications and implement your own code that would figure out if
this was a live-resize or not. For example, you could set a flag
and have a method that would reset this flag and invoke
'needsDisplay' after a delay using something like the method
'performOnce:withTarget:withObject:afterDelay' (see below). Then
your redraw method could look at this flag and react accordingly.
// performOnce:withTarget:withObject:afterDelay
// This is a utility routine that is used for postponing a selector
// until after some activity is finished.
// It is designed to be repeatedly called while the activity is
ongoing
// and it will result in the selector being invoked exactly once
// after the activity has finished.
+ (void)performOnce:(SEL)aSelector
withTarget:(id)aTarget
withObject:(id)anArgument
afterDelay:(NSTimeInterval)delay
{
// cancel any pending requests of this type
[NSObject cancelPreviousPerformRequestsWithTarget: aTarget
selector: aSelector
object: anArgument];
// schedule the request
[aTarget performSelector: aSelector
withObject: anArgument
afterDelay: delay];
}
--
Cameron Hayne
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden