home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!mcsun!corton!dmi.ens.fr!basilic!espie
- From: espie@basilic.ens.fr (Marc Espie)
- Newsgroups: comp.sys.amiga.programmer
- Subject: Re: ASL and GadTools libraries.
- Message-ID: <1992Jul29.134051.28073@ens.fr>
- Date: 29 Jul 92 13:40:51 GMT
- References: <1992Jul27.191144.25772@wam.umd.edu> <33732@cbmvax.commodore.com> <1992Jul28.172522.23855@wam.umd.edu>
- Sender: news@ens.fr (USENET News System)
- Organization: LIENS, ENS, 45 rue d'Ulm, Paris (France)
- Lines: 42
- Nntp-Posting-Host: basilic.ens.fr
-
- In article <1992Jul28.172522.23855@wam.umd.edu> stark@wam.umd.edu (Mike Stark) writes:
- >In article <33732@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes:
- >> In article <1992Jul27.191144.25772@wam.umd.edu> I write:
- >>> I wish the autodocs said this was OK because I really want to let the user
- >>> of my program close windows while the ASL requester is active.
- >>
- >> The autodocs WON'T say it's OK because it's NOT. If you want to close
- >> the window while the requester is active, then don't pass your window
- >> in as a reference window. It's pretty simple.
- >
- >Well, I think you misunderstood me a little bit. I realize that what I
- >am doing is not a good idea. However, I have a program that has several
- >windows open on one IDCMP one of which may be the ASL file requester. I
- >wanted to have one process service all of these windows and I thought that
- >the ASL hook function provided a way to do that while the ASL requester was
- >alive. Unfortunately, it is clear from the documentation (And now painfully
- >clear that the documentation represents not only the fact but also the
- >intent of C/A) that I will have to fork off another process just to open
- >up the ASL requester.
-
-
- From my point of view, this is a BIG design error in the ASL
- requester. That hook function mechanism is not as useful as it could
- be. For instance, you can just get messages from Intuition. If you want
- to write a program that takes external events into accounts (timer
- stuff and others), you can't get them through that hook function. You
- have to fork another process anyway. The biggest problem for me is that
- we get away from the event-driven programming model: wait for next
- event, process it, and loop. We have to get several processes to do
- this kind of thing. This tends to get messy, as process
- synchronization is not exactly trivial. You have to have got through
- lots of mistakes before you get it right, since these bugs are sooooo
- unpredictable.
-
- Well, the documentation says you can't, so I shan't.
- But I sure hope this will change in the near future !
-
- --
- Marc Espie (espie@ens.fr)
- `In Unix, no one can hear you scream.
- Sys V R4, the final battle.
- The aliens are ALREADY among us.'
-