[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problems with *cursorhook* ?
- To: email@example.com
- Subject: Re: Problems with *cursorhook* ?
- From: firstname.lastname@example.org (Bill St. Clair)
- Date: Mon, 18 May 1992 15:48:36 -0500
- Cc: email@example.com
>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
>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)
> ; cursor tracking is lost!
You should BIND *cursorhook*, not set it. The default value is what
provides the default cursor behavior:
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.