Panel/Form Widget

[hakan at exformedia.se]

Maybe I don’t understand your idea but I do think you have kind of  the same using a group. If you design your group or your ”panel” you still need to place your controls. If you move a group you also move the controls within that group. You can also grab individual controls in a group if you click on the ”Select Grouped” button.
If you do want to place them programmatically you do have a relation as all groups can know their children via ”of me”:

repeat with i = 1 to the number of controls of me
   set the loc of control i of me to <whatever>
end repeat

Every control also know their parent via ”the owner”:
dispatch ”controlSelected” to the owner of me with the long id of me

Groups also get a message ”resizeControl” that I have used a lot when creating my own ”controls” consisting of several controls in a group.

I can see the advantage if you are to build a fairly complex multi window layout but still what to keep a one-window layout (ala Photoshop). But even that should be doable with groups alone as if you drag a palette to be free-floating you could create a new palette window and clone the group to that window.

I usually drag out the controls and place them where I want them and then select them and ”Group” them afterwards. If I want that exact group in another project I can clone the group in one way or another.

So I can’t see the big difference...

But maybe [probably] I’m missing something…

:-Håkan
On 11 Apr 2019, 15:27 +0200, Dalton Calford via use-livecode <use-livecode at lists.runrev.com>, wrote:
> Hi Richard,
> Thanks for your response!
>
> So for the foreseeable future, we have groups, sharable within a stack,
> > and clonable anywhere, even into other stacks. Using that as a
> > foundation, we may be able to write a handler or two to give you a very
> > Viewer-like experience, if you can share more about the particulars of
> > how you'll be using them.
> >
>
> Although I can see the use of groups as an option, it is far less
> intuitive and causes more issues than it should.
> For example.
> Calculating where to place/move an object within a group requires
> calculating where you want a new widget or where to move a widget in
> regards to the rest of the group, getting the top left corner of the group,
> combining the result etc., all in code.
> A parent/child with relative positioning is far simpler and closer to all
> modern systems.
> Another example,
> During development, in other apps, you drop a panel, drop your new widgets
> upon it as needed, and that is it.
> With Livecode, you either do not create the group until you are absolutely
> sure you know what you want in it, or, baring that, play with code or the
> project browser to move items into an existing group.
> Plus, using the pointer tool to move items within the group is also not
> possible as the items in the group are the items you use to click upon to
> move the whole group.
>
> This is a frustrating issue for what should be a simple thing. A
> 'container' would be the solution - effectively a smarter group, with
> widgets having a 'parent' and a possible array list of 'children'. This
> would allow a 'child' to know it's parent, and a 'parent' to know its
> children. Event notifications such as changes in geometry, style, etc
> could then be triggered/passed. It would also allow for simpler
> cropping/scroll bar mechanisms.
> It would also act as a scoping mechanism for variables and events.
>
> You could even have a stack as a child of another stack with this setup
> (MDI interface).
>
> If I had a better understanding of the codebase, I would implement it
> myself.
> But, If I had a better understanding of the code base, I would rather spend
> my time on the database layer which is woefully limited.
>
> best regards
> Dalton
>
> On Wed, 10 Apr 2019 at 18:11, Richard Gaskin via use-livecode <
> use-livecode at lists.runrev.com> wrote:
>
> > Dalton Calford wrote:
> >
> > > In other programming languages/environments that I have used, there is
> > > a normally a panel object.
> > > In livecode terms, it would act like a stack that is embedded inside
> > > another stack as a widget.
> > > With Delphi, it is a panel (tabbed; normal or repeating) while in
> > > MSAccess it is a form (repeating or not).
> > > My question is, does such a thing exist in livecode?
> >
> > LC has groups, which can contain any number of objects, and when nested
> > can even work like having multiple cards within them. They can be
> > shared across any card within a stack, but not across stacks*.
> >
> > Nice for some things, but if you want a true stack object within another
> > stack you may have to wait a while: this enhancement request is now 14
> > years old, for what Gain Momentum introduced to the xTalk world as
> > "Viewers"; while the LC team has shown interest in it, other priorities
> > have displaced its implementation:
> >
> > https://quality.livecode.com/show_bug.cgi?id=2786
> >
> > So for the foreseeable future, we have groups, sharable within a stack,
> > and clonable anywhere, even into other stacks. Using that as a
> > foundation, we may be able to write a handler or two to give you a very
> > Viewer-like experience, if you can share more about the particulars of
> > how you'll be using them.
> >
> >
> >
> > * Many years ago I experimented to find that you could display a group
> > in another stack, but that was never intended and crashed hard as soon
> > as you interacted with it. Turns out showing groups across stacks was
> > technically a bug, long since fixed. #HistoricalTrivia
> >
> > --
> > Richard Gaskin
> > Fourth World Systems
> > Software Design and Development for the Desktop, Mobile, and the Web
> > ____________________________________________________________________
> > Ambassador at FourthWorld.com http://www.FourthWorld.com
> >
> > _______________________________________________
> > use-livecode mailing list
> > use-livecode at lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode