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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,eafb0c0f59b030c X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.megapath.net!news.megapath.net.POSTED!not-for-mail NNTP-Posting-Date: Thu, 28 Sep 2006 22:15:44 -0500 From: "Randy Brukardt" Newsgroups: comp.lang.ada References: <3egSg.208528$1i1.141541@attbi_s72> <1159338085.495558.286500@i42g2000cwa.googlegroups.com> <7s2dnaT_9fw5nobYnZ2dnUVZ_tOdnZ2d@megapath.net> <_AHSg.210879$1i1.191702@attbi_s72> Subject: Re: Event mechanisms for GUI's Date: Thu, 28 Sep 2006 22:16:02 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Message-ID: NNTP-Posting-Host: 64.32.209.38 X-Trace: sv3-Bq5s3TTkPH5liAe7xwtI6UplROFJK2CuaTG71RAZHgcSlQMZ/IH3kqBcfbdiFWk3MkVzJNhYWlasosy!OdpFvItInqsFWYBsoscPirboHXCZ/Eo24zpJfdx27nTOL1Sy+BgLf77A9bMgfK30yZBJnYE6nL+c!Ms9YIFKXd181Rw== X-Complaints-To: abuse@megapath.net X-DMCA-Complaints-To: abuse@megapath.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news2.google.com comp.lang.ada:6802 Date: 2006-09-28T22:16:02-05:00 List-Id: "Jeffrey R. Carter" wrote in message news:_AHSg.210879$1i1.191702@attbi_s72... > Randy Brukardt wrote: ... > > First of all, there is no simple or even satisfactory solution to this > > problem. The trouble is that handling asynchronous events in a sequential > > programming language (or even a high-level parallel one like Ada) is a poor > > match. You complained about "a subprogram being called when a framework > > pleases", but you have the same effect with any mechanism - the order of > > operations depends on the events, not on the program. And any well-designed > > framework will make it clear when subprograms will be called and by which > > task. > > With configurable event queues, the user decides when events will be > processed. With a callback mechanism, the framework makes those decisions. That's *usually* a good thing -- it hides a lot of irrelevant detail from the user, so they can concentrate on the important things. After all, 99% of the time, you simply want to handle menu selections -- you don't care how those are done. Yes, there is that 1% that might be harder, but I'm really dubious that there is any one-size-fits-all solution. ... > > My final conclusion is that all of the solutions have severe trade-offs; > > none is anywhere near optimal. My advice to the OP is to select a strategy > > that works well for the problems that they want to solve, and not worry too > > much about "goodness" -- it's not going to happen in a GUI (that's why GUI > > builders are so indispensable). > > I've used callback, dispatching, and event-queue GUIs, and I prefer the > latter. The code is much clearer. My experience with Windows message loop (which is just a poorly implemented event queue) using our old Win32 binding (which covered up the ugly stuff) was that short programs were easier to write and understand, but that it didn't scale well. And reuse was near impossible; that's easy for the tagged dispatching version. OTOH, the dispatching version requires writing a type and a bunch of subprograms for typical simple uses -- which is annoying. So I think it is a case of many trade-offs, but no solution that is clearly better. Randy.