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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.107.144.130 with SMTP id s124mr17575955iod.4.1495683932458; Wed, 24 May 2017 20:45:32 -0700 (PDT) X-Received: by 10.157.35.104 with SMTP id k37mr296701otd.14.1495683932427; Wed, 24 May 2017 20:45:32 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!67no304331itx.0!news-out.google.com!m134ni1359itb.0!nntp.google.com!67no304326itx.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 24 May 2017 20:45:32 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=173.71.201.205; posting-account=QF6XPQoAAABce2NyPxxDAaKdAkN6RgAf NNTP-Posting-Host: 173.71.201.205 References: <05ed8053-be36-4332-8b75-7bca9afd65cc@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Preventing private procedure visibility being made public through extension From: Jere Injection-Date: Thu, 25 May 2017 03:45:32 +0000 Content-Type: text/plain; charset="UTF-8" Xref: news.eternal-september.org comp.lang.ada:46862 Date: 2017-05-24T20:45:32-07:00 List-Id: On Monday, May 22, 2017 at 5:24:11 PM UTC-4, Jeffrey R. Carter wrote: > On 05/22/2017 12:46 AM, Jere wrote: > > with Gnoga.Gui.Window; > > with Gnoga.Gui.View; > > package Gnoga.Gui.Modal_Dialog is > > > > type Dialog_Type is tagged limited private; > > type Dialog_Access is access all Dialog_Type; > > type Pointer_To_Dialog_Class is access all Dialog_Type'Class; > > > > procedure Create > > (Dialog : in out Dialog_Type; > > Parent : in out Gnoga.Gui.Window.Window_Type'Class; > > ID : in String := ""); > > > > private > > > > type Dialog_Type is new Gnoga.Gui.View.View_Type with record > > Main_View : Gnoga.Gui.View.View_Access := null; > > end record; > > > > end Gnoga.Gui.Modal_Dialog; > > I don't see any reason for the access type in the full view. It could probably > just be View_Type, but I think it should really be > Gnoga.Gui.Element.Form.Form_Type, as I'll explain later. In my original attempt, I ended up passing back an access value via a function. In order to avoid having to pass an Unchecked_Access from an aliased parameter, I went full access type under the hood. Based on your later example, I scrapped that. > > > The other option I was tossing around was to > > instead add a > > > > procedure Add_Component > > (Dialog : in out Dialog_Type; > > Object : in out Gnoga.Gui.Base.Basetype'Class); > > Mostly what people need in such a dialog are buttons and text widgets > (Text_Type). The former are from Gnoga.Gui.Element.Common and the latter from > Gnoga.Gui.Element.Form, which is why I think your inner view should be a form. > You can create buttons with a form as the parent, but you can't create a text > widget without a form. (This seems wrong to me, but that's how Gnoga is. I've > often used form widgets but never needed the form functionality.) So as a first > cut you could only have > > procedure Create_Button (Button : in out Button_Type; > Content : in String := ""; > ID : in String := ""); > > procedure Create_Text (Text : in out Text_Type; > Size : in Positive := 20; > Value : in String := ""; > Name : in String := ""; > ID : in String := ""; > Label : in String := ""); > > and you'd probably cover 95% of uses. Internally, you'd call Button.Create with > your form as Parent, and Text.Create with your form as Form. Your client can > then attach an on-click handler to the buttons and call Value for the text > widgets. If Label is not null, you would create a label to go with Text with > Label as its Content. > > You might also want to provide a Create_Div that the client could put a bunch of > text into, and a New_Line for putting things on different lines. So you could > have dialogs like > > > > So you'd have to write a number of these Create operations, but there wouldn't > be too many of them. I'd want to limit what kinds of things a client can put in > a dialog, and maybe how many of them, too. I get that, and I like the idea. I'm not sure I agree with the limitations suggested. I don't see why doing what you suggest for just a view type wouldn't cover all cases and still limit access to the internals of the tagged type. I ended up thinking on this and playing around with it. I scrapped the internal access type, and I then added a new procedure: procedure Create_Main_View (Dialog : in out Dialog_Type; View : in out Gnoga.Gui.View.View_Type: ID : in String := ""); That way, they can setup whatever view with whatever components they want and my Dialog_Type just supplies the Modal operations to use it. If they have a new custom type already defined, then they can just create an intermediate view to hold it and pass that in. I'm still playing with it as my kids allow me time, but so far it has most of my bases covered. I think my only snag so far has to do with the mechanics of width and height parameters. I'll probably fire up a question in the gnoga list for that since it is more HTML/Gnoga based in nature. I know it isn't exactly what you suggested, but hopefully it is still a good way to go. I don't want to fully limit what types can be used in the dialog because someone might want to do something complex like a portable file chooser dialog (for standalone apps). In cases like those, I would want to be able to at least help support custom widget types. Maybe I am overthinking it though. > > But probably if you use Gnoga.Gui.Plugin.jQueryUI.Widget.Dialog_Type with Modal > => True you can save yourself the effort. I didn't realize they had added that. I'll play with it some to see how it works out. I'm still playing with my handmade one if only to learn more, but this is a good point and I should experiment with the jquery one.