How's that for an obscure subject line? Please note that the code I'm
working on is happily 10.5 only, so if there's some Leopard-only magic
you want to invoke to answer, feel free.
I have some sketching code that I'm working on, and am trying to make
it unit-testable. The basic flow is:
mouseDown:
- start a mark with that pt
- turn off mouse coalescing with + [NSEvent
setMouseCoalescingEnabled:NO];
mouseDragged:
- continue a mark with that pt.
- while we're still getting mouse dragged events, keep continuing the
mark, enlarging the dirty rect
- finally, set the view's dirty rect based on all the mouse dragged
activity, which causes the view to redraw that part of itself
mouseUp:
- finish off the mark
- turn mouse coalescing back on
We do the while loop with this code, where "e" is an NSEvent*:
while (e = [NSApp nextEventMatchingMask:NSLeftMouseDraggedMask
untilDate:[NSDate distantPast] inMode:NSEventTrackingRunLoopMode
dequeue:YES]) {
// transform point appropriately, etc. etc.
}
Please note that if I don't turn mouse coalescing off, I don't get a
satisfactory number of points (I'm using a Wacom, not a mouse), and if
I just use mouseDragged and don't group the points before marking the
view dirty, the redraw will lag far behind the user's hand.
So I'm trying to write a "DemoMonkey" class to drive the view
programmatically so that I can simulate the user mousing down,
dragging, and mousing up, so I can both debug now and build unit tests
for later.
I'm trying to decide if I can/should just try and inject a bunch of
NSEvents into the stream, or if I should abstract this code a wee bit
more and then pull all the points out of the queue myself from one
level above, and then call a modified version of this routine that
take a known set of points, and then have the unit test call that.
Given that I'm coming somewhat late to the unit testing game, I'm
assuming lots of people have thought about this and come up with
satisfactory answers before me....
