home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / windows / x / motif / 8178 < prev    next >
Encoding:
Text File  |  1992-12-22  |  2.2 KB  |  47 lines
  1. Newsgroups: comp.windows.x.motif
  2. Path: sparky!uunet!spool.mu.edu!sol.ctr.columbia.edu!destroyer!cs.ubc.ca!mprgate.mpr.ca!lichen!janzen
  3. From: janzen@lichen.mpr.ca (Martin Janzen)
  4. Subject: Re: two processes with one window?
  5. Message-ID: <1992Dec22.211402.2296@mprgate.mpr.ca>
  6. Sender: janzen@lichen (Martin Janzen)
  7. Reply-To: janzen@mprgate.mpr.ca
  8. Organization: MPR Teltech Ltd.
  9. References: <1992Dec18.144058.20973@walter.bellcore.com> <3944@creatures.cs.vt.edu>
  10. Date: Tue, 22 Dec 92 21:14:02 GMT
  11. Lines: 34
  12.  
  13. In article <3944@creatures.cs.vt.edu>, ramakris@csgrad.cs.vt.edu (S.Ramakrishnan) writes:
  14. >In article <1992Dec18.144058.20973@walter.bellcore.com> john@bivalve.bellcore.com (John Snow) 
  15. >writes:
  16. >  >I have a situation where I want a background program to have control of
  17. >  >a portion of a window, specifically a drawing area.  It would be nice if
  18. >  >I could fork off another process and pass it the widget id of the drawing
  19. >  >area, but I know things couldn't possibly be that easy.  Is it possible
  20. >  >to do something like this, and if so, could someone give me some hints
  21. >  >as to how to do it?
  22. >
  23. >[good advice deleted]
  24. >
  25. >Prior to forking, you may store the window id of 
  26. >the drawing area and the (x,y,width,height) of the section that the child needs to 
  27. >manage in a rootwindow property and have the child access it after it comes up.
  28.  
  29. This is a good way for unrelated processes to share information, but it's
  30. not really necessary in this case.  The parent simply needs to store the
  31. above information in some variables; the fork() call will make a copy
  32. of the parent's data area for the new child process.
  33.  
  34. >Unless the drawing/repainting of the drawing area is unusually complex, the gain in
  35. >execution efficiency does not warrant the yucky implementation that
  36. >is bound to result with the use of forking.
  37.  
  38. Agreed!  Though if John _must_ have truly asynchronous updates to the
  39. drawing area even when the parent process is busy and can't process
  40. events, there may not be any alternative.
  41.  
  42. -- 
  43. Martin Janzen                     janzen@mprgate.mpr.ca (134.87.131.13)
  44. MPR Teltech Ltd.                  Phone: (604) 293-5309
  45. 8999 Nelson Way                   Fax: (604) 293-6100
  46. Burnaby, BC, CANADA  V5A 4B5
  47.