home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / windows / x / motif / 7508 < prev    next >
Encoding:
Internet Message Format  |  1992-11-16  |  2.6 KB
  1. Path: sparky!uunet!think.com!ames!agate!ucbvax!oceanroutes.ns.ca!deveau
  2. From: deveau@oceanroutes.ns.ca ("Terry J. Deveau")
  3. Newsgroups: comp.windows.x.motif
  4. Subject: Re: POSITIONING of dialog boxes. How do I do that ???
  5. Message-ID: <9211161528.AA28029@BU.EDU>
  6. Date: 16 Nov 92 15:26:57 GMT
  7. References: <MAN.92Nov14190555@imrryr.at>
  8. Sender: daemon@ucbvax.BERKELEY.EDU
  9. Distribution: inet
  10. Organization: Oceanroutes Canada Inc.
  11. Lines: 48
  12.  
  13. Andreas Manessinger <man@magwien.gv.at> writes:
  14. > 
  15. > What I want (ideally) is, that new boxes are always created in the
  16. > proximity of the mouse pointer.
  17. > 
  18. > What I tried is:
  19. > 
  20. >         Creating the widgets as children of the box that contains the 
  21. >         initiating push button and setting `XmNdefaultPosition' to
  22. >         `true'. This works quite well, the widgets appear in a
  23. >         position centered to their parent, but I look for a solution
  24. >         that works NOT ONLY AT CREATION TIME. Besides from that, I
  25. >         couldn't iconify my whole application by iconifying the main
  26. >         window any more.
  27. > 
  28. I don't know how to solve your main problem; however, on the question
  29. of the whole application iconifying with the main window or not, what
  30. I have noticed is that this works properly when each XmDialogShell is
  31. made the child of the container widget which is the sole child of the
  32. XmDialogShell one level higher up.  Any other relationships seem to
  33. mess-up the iconification.
  34.  
  35. If you are using XmCreateFormDialog (for example), you will have to
  36. do something like this:
  37.  
  38.             app_shell = XtInititalize (...)
  39.             main_win = XmCreateMainWindow (app_shell, ...)
  40.             work_area = XmCreateForm (main_win, ...)
  41.             level2 = XmCreateFormDialog (work_area, ...)
  42.             level3 = XmCreateFormDialog (level2, ...)
  43.  
  44. Note that I have not shown the widgets (pushbuttons, menus, etc.) that
  45. are needed to have the user open the dialogs, the XmCreateFormDialog
  46. calls would go in the callback functions of those widgets.
  47.  
  48. Note also that XmCreateMainWindow works a little differently from the
  49. general rule; can omit it if you don't need it.
  50.  
  51. Doing things this way, the dialogs usually come up centred on the
  52. widget that generated the callback (even though it's not formally
  53. in the hierarchy for the new dialog), whether the mouse or keyboard
  54. was used to generate the callback.  On some callbacks triggered by
  55. the keyboard (in particular the Help() action), the triggering
  56. widget is unmanaged before the new dialog is created; the new dialog
  57. then seems to come up almost as far away as possible from the location
  58. where the triggering widget used to be.  Isn't motif wonderful!
  59.  
  60. ... Terry
  61.