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@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@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 > > ____________________________________________________________________ > > ambassa...@fourthworld.com http://www.FourthWorld.com > > > > _______________________________________________ > > use-livecode mailing list > > use-livecode@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@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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode