[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems with *cursorhook* ?



>When I set *cursorhook* to a cursor I have obtained from a resource
>file, the cursor shape appears as desired.  When I reset *cursorhook*
>to nil, the system doesn't seem to track the cursor correctly.
>
>For example, when a cursor is over the scoll bars in a fred window,
>the cursor shape remains an I-beam.  Clicking on a scroll bar changes
>the cursor to an arrow, but then it remains an arrow until you click
>in the content region of the fred window where it then returns to an
>I-beam.
>
>Furthermore, if you initiate an event with *cursorhook* bound to
>a different cursor than the default cursor, the cursor changes to the
>default cursor.  For example, let's say that I have set *cursorhook*
>to some *foo-cursor*.  Selecting some text in a fred-window (by 
>clicking and dragging) changes the shape of the cursor from *foo-cursor*
>to the normal I-beam for a fred-window.  From my understanding of
>*cursorhook*, this shouldn't happen - the cursor should remain
>*foo-cursor* no matter what the user does if *cursorhook* is bound.
>
>I look forward to any replies, as completely controlling the shape
>of the cursor is critical to my application.  THANKS.

There is a call to SET-CURSOR in the code called by the VIEW-CLICK-EVENT-HANDLER
method for the FRED-MIXIN class. This is a bug. It should call UPDATE-CURSOR
instead. If you tell me which version of MCL you're using, I'll send you a patch.
Remind me of "FRED-CURSOR-PATCH".

...

>? (setf *cursorhook* nil)
>nil
>
>  ; cursor tracking is lost!

You should BIND *cursorhook*, not set it. The default value is what
provides the default cursor behavior:

? *cursorhook*
CCL::CURSORHOOK
? 

The WITH-CURSOR macro may be what you want. You may also want to consider
writing a VIEW-CURSOR method for your window or view.