Path: utzoo!attcan!uunet!wuarchive!julius.cs.uiuc.edu!apple!agate!ucbvax!ATHENA.MIT.EDU!wdc From: wdc@ATHENA.MIT.EDU (Bill Cattey) Newsgroups: comp.soft-sys.andrew Subject: Issues in dialogue box creation. Message-ID: Date: 19 Oct 90 06:58:18 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 41 I've written compiled and tested my im_CreateTransient code. It works. It has a *bad* interaction with the existing Andrew dialogue boxes. My transient windows come up in front of the Andrew window. (They have to in order to be seen.) If an Andrew dialogue box comes up, it's text is obscured, but it grabs all the window events. This means that you can't see what action it's going to take, but you are forced to deal with it before you can deal with my Transient window. You can't even get rid of my transient, since there is no way an event to do so can get past the Andrew dialogue box. As I see it, there are two solutions: 1. Modify the event grabbing code of Andrew dialogue boxes to be less nasty to transients. 2. Rewrite Andrew dialogue boxes to use im_CreateTransient. My inclination is to throw away and rewrite the existing dialogue box code. I don't think I could quickly enough come to an understanding of the hair of the existing dialogue boxes. As I understand it, these dialogue boxes are of extremely limited functionality and should be easily replacable with new code. Everyone has been saying what a hairy crock the code is anyway. I believe the only real problem would come from the wm side of the fence. Is it possible for wm to create transient overlapping windows? If not, this could end up as a bad, user-visible change to the interface, and I don't want that. I guess a solution to such a problem would be to keep the old dialogue box code around conditionalized on the non-existance of transients. What do people think I should do? -wdc P.S. If anyone sent any design criticism, I've not received it. I'm flying blind here, and would very much like feedback.