From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e429176c9adb07b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-02-19 05:25:53 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!peernews-us.colt.net!newsfeed.news2me.com!newsfeed2.earthlink.net!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!stamper.news.atl.earthlink.net!harp.news.atl.earthlink.net!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: [OT] Best way to isolate a GUI? Date: Wed, 19 Feb 2003 08:06:34 -0500 Organization: MindSpring Enterprises Message-ID: References: <3E511C15.1040404@acm.org> <3E5121BD.4010200@cogeco.ca> <3E527506.6070209@cogeco.ca> NNTP-Posting-Host: d1.56.bd.03 X-Server-Date: 19 Feb 2003 13:07:44 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Xref: archiver1.google.com comp.lang.ada:34225 Date: 2003-02-19T13:07:44+00:00 List-Id: Well, for the sender, there needs to be only one queue. For the receiver, you're ultimately going to end up with case statements - either one big giant one explicitly created or a bunch of smaller ones inside various handling tasks or ones that are built for you via dispatching. I have not given the idea hundreds of hours of thought yet, but I'm sure a workable solution does exist. I've just never liked callbacks and thought that receiving messages in some manner is a much better answer. I've worked on systems (mostly LockMart stuff, but I know other companies did it) where there is an underlying messaging system where applications "register" for the messages they want to receive & create "mailboxes" to receive them. You basically end up with one process per computer that acts as the "mailman". It makes for a reasonably simple & elegant design of an app where a given task need only hear about the things it wants to do something about. It solves a lot of other problems along the way like socket overhead and needing to know about what else is out there attempting to communicate. It has its problems too, but in general its a good way to build loosely coupled distributed applications. I could imagine something similar working in a client/server mode to build an independent GUI without callbacks or excessively big case statements. You create a task for each window and it registers for events relating to that window. Its still got to have a case statement - or some kind of dispatching - but its localized. MDC -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/ Send Replies To: m c o n d i c @ a c m . o r g "Going cold turkey isn't as delicious as it sounds." -- H. Simpson ====================================================================== Warren W. Gay VE3WWG wrote in message news:3E527506.6070209@cogeco.ca... > > But this still suffers from one problem: Each queue in your task > would then have a monster case statement to split out the work > according to the widget that is receiving the event. Compare this > to the registered callback where only the interested widget for > the event gets the callback. No big case statement required for > event, or widget. > > Don't get me wrong.. I like the idea of queues and tasks. But this seems > a clumsy thing beside a callback. >