Hrvoje Niksic <hniksic(a)srce.hr> writes:
> Place the mouse pointer over the scrollbar, evaluate the following
> code and drag the scrollbar:
> (event-over-modeline-p (next-event))
> For me, it crashes:
for me too.
the problem is that the event returned contains a window in the
channel field. AFAICT this should be a frame (or console)!
The evil is contained in x_update_vertical_scrollbar_callback( )
in line 468 there is a call
signal_special_Xt_user_event (win, Qscrollbar_page_down,
but signal_special_Xt_user_event() is expecting a channel as the first
argument and stuffing it directly into the newly created event!
Wow, this must have been this way for ages (I only have 20.4 handy but
the Changelog doesn't contain anything relevant).
I guess what saved us, is the very lucky definition of event-frame
(defun event-frame (event)
"Return the frame that EVENT occurred on.
This will be nil for some types of events (e.g. keyboard and eval events)."
(fw-frame (event-channel event)))
which will always return a frame. So if anybody is in the right mood
remove the call to fw-frame and see what breaks :-)
I have to leave in a second. Maybe some X/event-handling expert can
fix this. If not I will look into it tomorrow.
BTW: when using the 'pobj' defined in dbxinit I get the following
error for some object types (like windows for example :-)
(dbx) pobj object
"lrecord_toolbar_data" is not defined in the scope `xemacs`print.c`Fprint`
strange... lrecord_toolbar_button *is* defined but
lrecord_toolbar_data isn't -- any ideas??
Natural Language Systems Group, University of Hamburg