amc@wlv.imsd.contel.com (Allen M. Cohen) (01/16/91)
I have 2 client processes. Process_1 spawns Process_2. How can I have Process_1 popup an XmCreateWorkingDialog (with no buttons managed), and then have Process_2 popdown or destroy that Dialog? I tried passing the XmCreateWorkingDialog's Widget ID as an argument to Process_2, and then having Process_2 doing XtDestroyWidget on it, but that didn't work. Thanks in advance. <> Allen M. Cohen Internet: amc@wlv.imsd.contel.com <> <> 3041 E. Black Hills Ct. UUCP: elroy.Jpl.Nasa.Gov!agi0!allen <> <> Westlake Village, Ca. 91362 Telephone: (805) 498-9611 ext. 195 <> <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
john@quonset.cfht.hawaii.edu (01/17/91)
In article <1991Jan16.035551.20623@wlbr.imsd.contel.com>, amc@wlv.imsd.contel.com (Allen M. Cohen) writes: > > I have 2 client processes. Process_1 spawns Process_2. > How can I have Process_1 popup an XmCreateWorkingDialog (with no buttons > managed), and then have Process_2 popdown or destroy that Dialog? > I tried passing the XmCreateWorkingDialog's Widget ID as an argument to > Process_2, and then having Process_2 doing XtDestroyWidget on it, but > that didn't work. Interclient communication via the X server is one means to aid in displaying of "work-in-progress" user feedback. It works like this: Process 1 sets up some atoms and then registers itself with the root window. It then execs process 2. Now, while process 2 is grinding through its startup, process 1 gives visual feedback to user. When process 2 is ready to remove the visual feedback, eg, realized its widgets or being mapped, it communicates these intentions back to process 1 (via XSendEvent). Process 1 then quits the visual feedback. Visual feedback could be a working dialog, flash buttons, etc. Depending upon what you are trying to use the feedback for, you could even have process 1 keep visuals up until it caught a SIGCHLD. This eliminates the interclient communication stuff. I think (not sure here) process 1 could also traverse the window tree and quit the visuals when process 2 was mapped (providing that is what it is going to do). Anyway, I hope this provides some food for thought. We have used the first two methods to give our users a clue that process 2 is indeed working -- just that it takes awhile to initialize all the X stuff and get mapped. jk ---------------------------------------------------------------------------- John Kerr Canada-France-Hawaii Telescope Corp. Computer Sys. Engineer INTERNET: john@cfht.hawaii.edu BITNET: john@uhcfht ----------------------------------------------------------------------------
tjhorton@vis.toronto.edu ("Timothy J. Horton") (01/18/91)
amc@wlv.imsd.contel.com (Allen M. Cohen) writes: >I have 2 client processes. Process_1 spawns Process_2. >How can I have Process_1 popup an XmCreateWorkingDialog (with no buttons >managed), and then have Process_2 popdown or destroy that Dialog? >I tried passing the XmCreateWorkingDialog's Widget ID as an argument to >Process_2, and then having Process_2 doing XtDestroyWidget on it, but >that didn't work. Widgets are parts of programs. Windows, on the other hand, are not. If you spawn a different program, it has a new set of widgets (a copy). The windows, on the other hand, are a different thing; both processes have the *same* socket connection and thus (conflicting) control over the same set of windows, until the socket is closed somehow (you don't want to play with this). What I would do is have process2 send process1 a signal, for which the signal handler in process1 would unmanage/popdown the dialog. If you are not using unix, you can still use property events, or ICCM (inter-client communication). Time to read up, if this is the case. [could not get personal mail through to originator] tjhorton@vis.toronto.edu