Re: drag-n-drop core dump
Colin Rafferty <craffert(a)ms.com> writes:
The first weirdness is that every time an XEmacs frame on my SGI
would
gain focus, it would pop up a "*MIME-Drop data*" buffer. I tracked
that down by replacing the `experimental-dragdrop-drop-functions' with
my own function that throws an error.
Is the SGI running unix or NT?
It appears that XEmacs thinks that it is getting a drop event, even
though it is a normal window-enter. Here are the event and object
from the callback:
event: #<misc-user-event (dragdrop-drop-dispatch (dragdrop-MIME
(("application/octet-stream") "8bit" "")))>,
object: (dragdrop-MIME ((application/octet-stream) 8bit ))
We must investigate the type of the actual ClientMessage XEmacs receives. I
append a patch which will output some debugging data. Please apply it and send
it's output (goes to stderr) to me.
Of course, it gets worse. When I then close the XEmacs frame on the
NT, the next time I move focus into an SGI frame, I get the following
stack trace on a SEGV.
So the NT station is only displaying a window from the SGI running unix?
2 x_event_to_emacs_event(0x7ffb70d8, 0x0, 0x0, 0x7ffb6e08, 0x0,
0x7ffb6d54, 0x0, 0x7ffb6cfc)
["/ms/user/c/craffert/build/xemacs/xemacs-21.0-b46/src/event-Xt.c":1151,
0x10162f24]
The path will modify the function above.
Weird: normally a client message is identified by an X atom. DndInitialize
will get/create this atom for XEmacs. All x_event_to_emacs_event does is to
look if this atom is also in the received ClientMessage. To get such an error,
there must be some fault in the allocation/use of this... we will see.
Regards,
Oliver.