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: Wed, 27 Sep 2006 18:05:07 -0500 From: "Randy Brukardt" Newsgroups: comp.lang.ada References: <3egSg.208528$1i1.141541@attbi_s72> <1159338085.495558.286500@i42g2000cwa.googlegroups.com> Subject: Re: Event mechanisms for GUI's Date: Wed, 27 Sep 2006 18:05:22 -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: <7s2dnaT_9fw5nobYnZ2dnUVZ_tOdnZ2d@megapath.net> NNTP-Posting-Host: 64.32.209.38 X-Trace: sv3-feThlbdhw2D5Ce6g2PVfDq+1XWMK7dtwUso0PN/uzcuuREhDn6Ij3rnsVqlZNgmkBSOSJw4Q0WG2L0/!APxGVjsScpuqxAxTbCWrpk1dAh5xIJJbQLeB/P+XiN9hagSZOgQA6ANZOu8Scgt+QFvJBj9hlkpv!f0VF7VDopj9T0A== 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:6785 Date: 2006-09-27T18:05:22-05:00 List-Id: "Jeffrey R. Carter" wrote in message news:D2CSg.992281$084.451732@attbi_s22... > Lucretia wrote: >... > > Also, I'd like this not to go off-topic too early. > > What mechanism provides the user with the clearest code, most control, > and ease of use is, I thought, the topic. I would agree, but I certainly would disagree with your conclusions. 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. Second, explicit event handling is among the worst solutions, because it requires an explicit response to every possible event. A real GUI system will have dozens, if not hundreds, of possible events for each Window. It's easy to forget to handle some of those events; moreover any *explicit* code necessary to do the *default* action reduces the readability of the system. And the easiest solution (the others clause) completely eliminates the main advantage of using case statements -- the completeness check. I'm not convinced that the "subprogram extension" solution used by Claw is the best one, and I'm certainly not convinced that the multi-task arrangement used by Claw is a good idea. (For a lot of systems, a single task solution with an explicit call-me-now routine would be easier to work with. But it would also make it a lot easier to starve the GUI - a problem that explicit events certainly have as well.) 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). Randy. .