home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / tcl / 2123 < prev    next >
Encoding:
Internet Message Format  |  1992-12-16  |  3.2 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!sprite.Berkeley.EDU!ouster
  2. From: ouster@sprite.Berkeley.EDU (John Ousterhout)
  3. Newsgroups: comp.lang.tcl
  4. Subject: Re: toplevel message widgets problem
  5. Date: 16 Dec 1992 16:35:17 GMT
  6. Organization: U.C. Berkeley Sprite Project
  7. Lines: 50
  8. Distribution: world
  9. Message-ID: <1gnls5INNpi0@agate.berkeley.edu>
  10. References: <1992Dec15.233825.18609@bcars6a8.bnr.ca>
  11. NNTP-Posting-Host: tyranny.berkeley.edu
  12.  
  13. In article <1992Dec15.233825.18609@bcars6a8.bnr.ca>, norm@bnr.ca (Norm MacNeil) writes:
  14. |> I wanted to be able to put up a "dialog" box with a message (like "Processing -
  15. |> Please wait...") and then allow the program to continue on until such time as
  16. |> the internal processing was complete at which time the message box would
  17. |> disappear.  So I wrote a little procedure...
  18. |> 
  19. |> So in the program, it would be used like...
  20. |> 
  21. |> MsgCntl BEGIN "Processing - please wait..."
  22. |> #life happens here
  23. |> MsgCntl END ""
  24. |> 
  25. |> Anyway, sometimes the text appears in the message window and sometimes it
  26. |> doesn't.  The above code is littled hacked up from the number of iterations of
  27. |> trying to get this to work.  One test, I got the message windows to display the
  28. |> text, exited from the program, and restarted it, and this time the text did NOT
  29. |> appear so I know it's not from code-fiddling.
  30. |> 
  31. |> What gives on the apparent inconsistency in displaying the text?
  32. |> 
  33. |> Thanks much in advance,
  34. |>   Norm.
  35. |> -- 
  36. |> +-----------------------------------------------------------------------+
  37. |>  Norm MacNeil                     Phone: (613) 763-7497
  38. |>  Data Systems                     Fax:   (613) 765-2854
  39. |>  Bell-Northern Research Ltd.      EMail: norm@bnr.ca (INTERNET)
  40. |>  #include <disclaimer.std>       "Roller bladers do it in-line!"
  41.  
  42. The inconsistency occurs because window creation and redisplay are delayed
  43. operations.  They don't occur until the application runs out of other work
  44. to do;  if you immediately go off to do something else after creating the
  45. window, the application doesn't run out of work to do so the window doesn't
  46. appears on the screen.  Putting an "update" after you've created the window
  47. will help, but even that isn't enough, since that will only *initiate* the
  48. process of creating the window.  The window redisplay is also delayed, so
  49. it might not complete before the update runs out of things to do (there's
  50. a round-trip to the server and/or window manager involved, so the application
  51. may think it's caught up before the window manager has actually mapped the
  52. window).
  53.  
  54. The bottom line is that you have to explicitly wait until you *know* that
  55. the window has been displayed.  The way to do this is with the tkwait command.
  56. Set up a binding for <Expose> on the window you want to see, with the
  57. binding set to modify a particular variable.  Then use tkwait to wait for
  58. the variable to change to the given value.  Once you know the window's up,
  59. then you can go off and do your other work.  Be sure to do one more update
  60. so that the window gets displayed, and also be sure to remove the binding
  61. when you're done.  Sorry this is so complicated... there should probably
  62. be a procedure in the Tk script library to do this automatically.
  63.