The cell consumes the event loop and dispatches events. Look at the
code via http://developer.apple.com/samplecode/PhotoSearch/listing9.html
ie:
if ([theEvent type] == NSMouseEntered || [theEvent type] ==
NSMouseExited) { [NSApp sendEvent:theEvent]; }
But do please log a bug; at worst, we c
Hi Corbin. Thanks for the note.
Well, the trouble is, if you are consuming the event loop, then you
need to dispatch things.
Have you seen: http://developer.apple.com/samplecode/PhotoSearch/
?
Yes, I studied this before I started and used the patterns in there.
The cell consumes the even
On Feb 4, 2009, at 5:51 PM, Luke Evans wrote:
OK, FWIW for the record here is the resolution I've arrived at:
mouseEntered and mouseExited events from tracking areas that are
active when mouse dragging begins are dysfunctional in the drag,
specifically when autoscrolling at the boundaries
On Feb 4, 2009, at 19:28, Luke Evans wrote:
Mmm. I'm going to have to check with you what this "fudgy thing"
actually is, in case I'm not doing something that is required
(officially or conventionally) to make things work. Certainly, I
was doing all my autoscroll during receipt of NSPerio
This really does sound like a coordinate system issue after all. It
may be a bug, or it may be correct but surprising behavior, or it
may be a gray area of expectation. It seems worth a bug report to
try to find out.
Indeed, I'll file one with as clear a description of the scenario as I
c
OK, FWIW for the record here is the resolution I've arrived at:
mouseEntered and mouseExited events from tracking areas that are
active when mouse dragging begins are dysfunctional in the drag,
specifically when autoscrolling at the boundaries of the cliprect. I
have a drag event loop per
On Feb 4, 2009, at 14:55, Luke Evans wrote:
Calling my own -updateTrackingAreas when I know the autoscroll has
occurred does not help at all - I can see the rectangles being
constructed with the correct locations, but the view still sends
events as if the scroll offsets within the clipView
Well, it's beyond any doubt in my mind now: my view's tracking areas
are not adjusted when I'm performing a drag operation and during this
operation an autoScroll is performed (in response to the user dragging
outside the visible rect of the view/clipView within the local
scrollView).
Cal
On Feb 3, 2009, at 22:49, Luke Evans wrote:
Incidentally, I thought I saw that logging the NSTrackingArea
instance when you've just created one, produces different output to
logging the instance sent to you in a mouse event (i.e. the
descriptions were different). I'm sure that's no more th
Thanks Quincey for your thoughts.
The evidence you've cited so far only points to the tracking area
being in the "wrong" place, not necessarily to it being the wrong
tracking area. I'm inclined to think that the misbehavior is an
artifact of view coordinate systems.
Well, I'm pretty confi
On Feb 3, 2009, at 14:14, Luke Evans wrote:
This really looks like the tracking areas established on the view
when the original mouse down event (that starts the drag) are cached
and remain in play during the drag operation.
Can anyone confirm if this is the case?
I've never seen anything
This really looks like the tracking areas established on the view when
the original mouse down event (that starts the drag) are cached and
remain in play during the drag operation.
Can anyone confirm if this is the case?
Overtly updating the tracking areas after calling '-autoscroll:' by
di
I have an overridden -updateTrackingAreas to compute some tracking
areas in a table view. This is being called when I move the vertical
scroll bar, but I have an event loop to handle drag operations in
which I start NSPeriodic events and call -autoScroll on the view when
the use drags out
13 matches
Mail list logo
