All widget in Cocoa inherit form a superclass named NSControl, and the basic concept is target/action: you set a target to a widget (instance variable), you tell it what action (selector) to call on that target. The action method only takes one argument, the widget itself, which is close to the event source we use in dynapi. Once you get it, you can ask it whatever you want.
Buttons for example would only call the action when a full click happens. But you can set a controls to continuously, at regular interval, send the action message while the mouse is down, which is obviously the case for a scroller. So controls responds to:
- (BOOL)isContinuous
- (void)setContinuous:(BOOL)flag
I've been programming with this paradigm for many years, and it's really working. For the same reasons I mentioned for the delegate, in the case of a scroller object, only one object is going to need to interact with it, which means that the event/notification is totally overkill for this type of usage.
How a Scroller Interacts With a Container View
NSScroller is a public class primarily for programmers who decide not to use an NSScrollView but who want to present a consistent user interface. Its use outside of NSScrollViews is discouraged except in cases where the porting of an existing application is made more straightforward. Setting up an NSScroller with a custom container view class (or a completely different kind of target) involves establishing the standard target and action as defined by NSControl, and implementing the target's action method appropriately.
As an NSScroller tracks the mouse, it sends an action message to its target with itself as the argument. The target then performs the scrolling operation based on these things:
• The orientation of the NSScroller, vertical or horizontal, which determines the axis to scroll along. This can be done by getting the NSScroller's frame and determining the longer dimension, or by keeping a reference to designated vertical and horizontal scrollers (as NSScrollView does).
• The direction and scale of scrolling. NSScroller's hitPart method returns this information, described in more detail below.
• If the hit part is the knob or its slot, the NSScroller's value, which indicates where to position the document view in the container view. The floatValue method provides this information, which the target should interpret relative to the size of the document view's frame minus the size of the container view's bounds.
As indicated above, the direction and scale of a scrolling operation is determined by the value returned from a hitPart message, which indicates the various parts of an NSScroller in terms of their intended result (not in terms of their location or appearance).
These part codes are interpreted differently depending on the method you use them with. See the individual method descriptions for hitPart, rectForPart:, and testPart: for details.
The four decrement/increment values require the target to calculate an appropriate amount to scroll by. Line and page amounts are up to the target or the container view to define. NSScrollView, for example, allows you to set these in Interface Builder or with its setLineScroll: and setPageScroll: methods. Once the target has scrolled the document view by a decrement or increment, it should update the NSScroller's position using setFloatValue:.
The container view or target should also keep tabs on its size and on the size and position of its document view. Any time these change it should update its NSScrollers using setFloatValueAndKnobProportionsetFloatValue:knobProp. NSClipView, for example, overrides most of NSView's setBounds... and setFrame... methods to perform this updating.
Benoit
On Friday, March 21, 2003, at 01:46 PM, Doug Melvin wrote:
I realize there would be a performance issue.
I was thinking more of a way to tell a specific layer to invoke a resize
event.
For now I'll just have the scroll bar extend the setsize method of the bound
layer
so that the scroll knob can be adjusted automatically.
onload would not just be for external documents.
--- Doug Melvin <[EMAIL PROTECTED]> wrote:
In the ChangeLog Dan had suggested that theonresize
event be replaced with the setAnchor() function.The
setAnchor() function is much more flexible thathaving
to do invokeEvent("resize")
So how do I respond to the resizing of a layer?
I really would like to know.
These are issues we will have to collaborate on. Is it
best to add invokeEvent inside the setSize() function?
How many apps/widgets will make use of the onresize
events? The pros and cons will have to be carefully
look at. Having invokeEvent inside setSize will slow
down animations and layers/widgets that makes use of
the anchor feature. If you say yes add the onresize,
then you'll have to add the onmove,etc events that
have been removed.
DynAPI 3.0 removed the onresize and onmove events. IMO
I don't think we need these events. I've found other
ways to solve my resize issues, but let's get some
feedback from the other developers.
Should be sacrifice add onresize,onmove and onload
back into 3.0?
We have about 7 active debvelopers, let hear the view
of as many as posible.
server)As for onload... It was suggested the theonCreate()
onPrecreate() functions be used to triggercallbacks
once the object (elm) is loaded.
See previous email (if it ever arrives on the
same as comment above.
--
Raymond Irving
__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://www.mail-archive.com/[EMAIL PROTECTED]/
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://www.mail-archive.com/[EMAIL PROTECTED]/
