On Oct 11, 2007, at 4:49 AM, Adriaan van Os wrote:
Jim, is this something we need ?
Not immediately. It isn't a stop-the-presses issue.
I modified the code to move the 'playback indicator' SpeedButton to
track mouse movement, which is good enough for right now. But the
playback indicator is higher in the window than this mouse-drag
gesture, and it would be clearer to the user if it would drag a line
which is actually under the mouse.
It also shouldn't be insurmountable to use a flag to indicate a
special 'mouse tracking draw' mode, and move the mouse tracking
drawing code into OnPaint. Then OnPaint would only do the special
mouse-tracking drawing according to the flag.
In that scheme, the MouseDown and MouseMove events would set the
special flag and then invalidate the TPaintBox and call
Application.ProcessMessages, which would trigger an OnPaint event and
put the changed image up on the screen.
Am guessing such a thing would work. It might be slow. It might run
thru so much code that it does not respond quickly to mouse movement.
The main intended OnPaint stuff in LCL is working nicely, and it is
complicated down there in the LCL. Admirable work to get it mapped
into Carbon so well.
But there are many little trivial things you could do on a Mac 512 in
1986, which require pretty immediate screen access. I realize that
Apple has tried its best over the years to make this nearly
impossible (grin).
For one example, in a graphic application, click-drag drawing a
'marching ants' selection around a piece of a picture.
Or in a music notation program, drawing hilited notes quickly in
realtime, during playback.
'Little things' like that beg for more direct screen output than
invalidating a control and letting OnPaint do the work (eventually).
jcjr
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
