Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!spool.mu.edu!uunet!rosie!aozer
From: aozer@next.com (Ali Ozer)
Newsgroups: comp.sys.next
Subject: Re: programming question: Views and Mouse Events
Message-ID: <354@rosie.NeXT.COM>
Date: 6 Mar 91 18:07:18 GMT
References: <2229@fornax.UUCP>
Sender: news@NeXT.COM
Organization: Next Computer, Inc.
Lines: 44
Nntp-Posting-Host: twinpeaks.next.com

In article <2229@fornax.UUCP> laughlin@fornax.UUCP (Bob Laughlin) writes:
>... I have a View subclass that fills part of a window. I would like the
>View's mouseDown: method to be called when the window first becomes
>activated with a mouse click (assuming the mouse click was also in the View).

Give your view an acceptsFirstMouse method and have it return YES.  When a
window becomes activated by a mouse down, the view under the mouse is
interrogated to see if it would like to get that event:

	- (BOOL)acceptsFirstMouse
	{
	    return YES;
	}

>... Under 1.0 this matrix of sliders would track
>mouse drags over different sliders. Under 2.0 the same matrix
>(created in IB) only tracks the slider that was initially activated
>on the mouseDown:. If you drag the mouse over a different slider
>it does not get activated. Has this been disabled in 2.0 or is it
>just a different default?

In 2.0 the tracking behaviour of sliders in a matrix of sliders
was changed so that the initial slider is the active one until the
mouse up.  This prevents neighboring sliders from taking over as you
drag the mouse.  Typically users want to grab a slider and drag it
while looking elsewhere; losing the control of the slider just
because they moved a bit too much to the side is confusing.

I don't believe there were any 1.0 applications out there that depended
on this tracking behaviour.  In fact, a few applications ended up creating
many individual sliders rather than a matrix just to avoid this tracking
problem.

However, for those developers who wish their sliders to track as they did in
1.0, there's a hook: The prefersTrackingUntilMouseUp factory method in Cell
determines if a cell in a matrix tracks until mouse up is received or
until the mouse is dragged over a neighboring cell. The method in Cell
(which most subclasses of Cell inherit) returns NO; thus matrices of 
buttons act as they did in 1.0. SliderCell overrides this method to
return YES; thus it grabs on to the mouse until it's released. Subclassing 
SliderCell and having this method return NO should restore the 1.0
behaviour.

Ali, Ali_Ozer@NeXT.com