From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_05,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.6 X-Received: by 2002:a37:e301:: with SMTP id y1mr6192250qki.475.1631256981692; Thu, 09 Sep 2021 23:56:21 -0700 (PDT) X-Received: by 2002:a25:3086:: with SMTP id w128mr9130867ybw.139.1631256981427; Thu, 09 Sep 2021 23:56:21 -0700 (PDT) Path: eternal-september.org!reader02.eternal-september.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 9 Sep 2021 23:56:21 -0700 (PDT) In-Reply-To: Injection-Info: google-groups.googlegroups.com; posting-host=87.88.29.208; posting-account=6yLzewoAAABoisbSsCJH1SPMc9UrfXBH NNTP-Posting-Host: 87.88.29.208 References: <6133e791$0$6461$426a74cc@news.free.fr> <6134cb26$0$3697$426a74cc@news.free.fr> <6134db32$0$6461$426a74cc@news.free.fr> <6134dc71$0$3693$426a74cc@news.free.fr> <6134e03d$0$3372$426a74cc@news.free.fr> <61352d42$0$3749$426a74cc@news.free.fr> <944e2cf6-2e24-480e-b7f7-0e0e0f5082e7n@googlegroups.com> <6139be6f$0$12704$426a74cc@news.free.fr> <757da468-7b58-43c2-95e6-917b3212f7b2n@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: GtkAda callback and event From: Emmanuel Briot Injection-Date: Fri, 10 Sep 2021 06:56:21 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:62687 List-Id: > > type My_Button is new Gtk.Whatever_Path.Button_Type with record=20 > > User_Data : User_Data_Type;=20 > > end record; This is indeed the recommended approach. In practice, most widgets have a s= ingle callback per event type (so one for motion_notify, one for click, and= so on). All that's needed is the `Self` parameter which contains all relev= ant information. At least this was my experience based on the GPS source co= de, which is a relatively extensive GUI application. I don't remember the s= tats exactly, but there were just a few cases where this approach did not w= ork. And this is why we implemented the higher-level approach in GtkAda, wh= ere there are no possible errors in the type of parameters for callbacks. There are a few cases where you want to share the same callback subprogram = for multiple events, or multiple types of widgets for instance. In these ca= ses, you might have to fallback to using the generics to connect, along wit= h specifying a user data. As much as possible, I would recommend not using = this approach if you can avoid it.=20 I do not share Dmitry's distrust of generics, but for GUI applications I 10= 0% agree that an OO approach works much better indeed. The performance cost= is negligible in such contexts, and the flexibility is much needed. > User data is a property of the event not of the button. E.g. consider a= =20 > button to save file. The user data would be some Ada object responsible= =20 > for dealing with the file. What about other buttons? What about=20 > life-times of buttons? User data usually have a longer life span etc. Presumably you would have one callback procedure to deal with the file, ano= ther one to exit the application, another one to ask the user's name and wh= atever else. For all of these, you do not need user data and the high-level= callbacks provided by GtkAda are much easier to use. One contrived example where user data might be used is for instance: we hav= e one callback responsible for moving the cursor in an editor, and the user= data is used to pass UP, DOWN, LEFT or RIGHT to indicate which direction t= o move. But even in such a case, I would argue it is better to have four sm= all callbacks that call the same shared procedure, and still use the high-l= evel callbacks of GtkAda.