home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 7124 < prev    next >
Encoding:
Text File  |  1996-08-05  |  4.9 KB  |  96 lines
  1. Path: speedy.grolier.fr!usenet
  2. From: septh@club-internet.fr (Stephan Schreiber)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Q: Finding ASL Window ptr
  5. Date: 9 Apr 1996 22:14:04 GMT
  6. Organization: Grolier Interactive Europe
  7. Message-ID: <4632.6671T187T2660@club-internet.fr>
  8. References: <4k5th5$4tt@ousrvr3.oulu.fi>
  9. NNTP-Posting-Host: ppp-98-56.neuilly.club-internet.fr
  10. X-Newsreader: THOR 2.22 (Amiga;TCP/IP) *UNREGISTERED*
  11.  
  12.  
  13. On 06-Avr-96   15:02:13, Timo Karjalainen said about Q: Finding ASL Window
  14. ptr:
  15. > Some time ago I wondered how to get an ASL requester closed
  16. > without user intervention. One proposed solution was to send
  17. > the ASL requester window a fake IntuiMessage IDCMP_CLOSEWINDOW.
  18.  
  19. I'm afraid there's no solution to close an open ASL window. Dot.
  20.  
  21. > Now: How do I find this Window, and thus its UserPort? I'll need
  22. > that in order to put a Message there. :-D
  23.  
  24. > It would be most convenient if the ASL structure had a field in
  25. > it that would contain the address of the Window. This is, however,
  26. > not the case. (Well, its really ASL private information, but hey, I
  27. > *need* to get that thing closed somehow!)
  28.  
  29. > My program runs on a private screen. I know the addresses of all
  30. > open windows that are my own. Do I just have to step through the screen's
  31. > Window list and send a faked IDCMP_CLOSEWINDOW to all windows whose
  32. > address I do not have in the list of "known windows"? Is this even
  33. > legal? struct Screen has a documented Window ptr and struct Window has
  34. > a documented next Window ptr.
  35.  
  36. One better solution would be to spawn a separate process for each ASL
  37. requester that you open. This is what I do for EasyRequest(), and this allows
  38. me to have a "normal" EasyRequester (that is, no need to call
  39. BuildEasyRequest() and SysReqHandler()) while still processing input in other
  40. windows. If you like, I can send you some source code (in C, of course).
  41. On the other hand, just looking at the imsg->IDCMPWindow pointer in your
  42. ASLFR_IntuiMsgFunc hook might be enough to decide if the IntuiMessage applies
  43. to one of your windows or not. If not, then it must be for the ASL window.
  44.  
  45. > Hey, Amiga Tech, if you're reading this: I hope you'll fix the VERY BROKEN
  46. > ASL feature of IntuiMessage callbacks. For a program to do one-task
  47. > multiwindowing with more than one window handling user input at a time,
  48. > it really needs to do asynchronous ASL requesters! However, AslRequest()
  49. > only returns after the user is finished with the requester. If the only
  50. > way to process user input while in AslRequest() is to use the shared IDCMP
  51. > & callback feature, there must be a way to close an open ASL requester!
  52. > I really suggest you add to asl.library a function CloseAslRequest(), which
  53. > would take the address of an ASL requester structure and close the requester
  54. > if it was open.
  55.  
  56. > A better solution would be an AsynchAslRequest(). It would open and set
  57. > up the requester window and *return immediately*. Once the program notices
  58. > an IDCMP message that is for an ASL requester, it would pass the message
  59. > to an asl.library function that would process it. This function would return
  60. > NULL if the IDCMP event didn't lead to closing the requester, otherwise
  61. > it would return the address of the ASL requester structure.
  62.  
  63. Agree with you: a OpenAslRequest()/CloseAslRequest() pair would be ideal,
  64. along with a ProcessAslEvents() (or something similar, names are not that
  65. important here).
  66.  
  67. > In fact it would be best to have a CloseAslRequest() as well, and also
  68. > something to ReopenAslRequest(). Sometimes a program needs to close the
  69. > ASL requester while it for example closes the screen and reopens it in
  70. > another display mode. Reopening would bring the requester back just like
  71. > it was never closed, except that it would take into account possible
  72. > changes in the screen, like another font and adjusting requester size
  73. > or position if the screen has become smaller.
  74.  
  75. This should simply be built into the AslRequest() function, since it is
  76. supposed to re-use the same AslRequester structure from call to call. A simple
  77. screen size checking should be sufficient here.
  78.  
  79. > Additions like these are *necessary* for Amiga applications to be
  80. > consistently what Amiga is best known for: multitasking. With these
  81. > things done, Amiga applications could maintain full "internal multitasking"
  82. > capabilities and intuitiveness. Didn't the Style Guide say that quitting
  83. > a program should be possible at all times and that the user should be
  84. > given all power to do anything?áWell, ASL makes those things impossible.
  85.  
  86. > I think I'm not the only one who *just hates* file or other requesters that
  87. > disable them from doing anything else. Sometimes you *need* to able to do
  88. > something else while the requester is open. Once you can do a little
  89. > something, you'd expect you can do *anything* - also things like quitting
  90. > the program or changing (closing!) the screen on which the requester has
  91. > been opened. It's a matter of user-friendliness. It isn't very fun to chase
  92. > down every single requester window on a crowded screen.
  93.  
  94. > tikarjal
  95.  
  96.