Colin Rafferty <craffert(a)ms.com&gt; writes: > > But you start both XEmacsens with the same -display set, correct? > > I don't start two different XEmacsen. I start one on IRIX, and then > `make-frame-on-display' to the NT (under Exceed). Everything is in > one process. Hmm... > Maybe you are thinking of the Solaris and IRIX versions of XEmacs that > I run. I am pointing them each to the same original display, and then > `make-frame-on-display' to NT. Hmm... it seems that the OffiX code is only good for one display so it is now implemented. To make it multi-display proof I have to remember the atoms for the DnD events on a per-display base. But this will require some (much?) changes... Can I save the atoms to the XEmacs device/display/whatever context? > > then the > > next question is: why do the DnD atoms have different numbers? If they are > > created from the same display, they should be equal (at least this is the way > > I think it should be...). > > They are different because they are from different displays. The 152 > messages are from the IRIX display, while the 133 messages are from > the NT display. And this is the point where the 'original' atoms get overwritten, cause offix.c only keeps one set of atoms. > Maybe 152 is DND on NT? I don't know enough about the X interals to > make an intelligent guess. Correct. And it kills the original atoms and can't remember the others. > The fix would be to have the global variables dnd atom variable > (OldDndProtocol, DndSelection, etc.) be in an alist keyed off the > Display. In this way, `DndIsDropMessage' could check relative to the > Display in the `event' parameter. Yup, same conclusion. > You may want to think about doing something similar for all the other > stuff in `DndInitialize'. Everything is getting set to whatever the > latest display was created. This would be the correct way I have to do it. But this will also result in a (nearly) complete rewrite of the OffiX lib I use (something I always wanted to do but never found the time to...) > I just hope that Steve lets this fix into 21.0. Steven? I think I will not have the time to do this this week. Perhaps I can start this weekend. The simple solution would be only to fix the display/atom stuff (small change) or do the whole thing. How does this fit into the XEmacs 21.0 release schedule? Regards, Oliver.