Panel/Form Widget

[Dalton Calford]

Hi Hakan,

I am not saying groups are not workable, I am just saying, that in
comparison to other 'container' style controls on multiple other
development platforms, they are not as easy to use, nor as versatile.

In java, delphi, access, kde (the list goes on), you can do all the work
you are describing without a single line of code.
Drop a 'container widget' onto a form (stack), change the properties you
wish (transparency, mouse over, child flow, etc) and drop the widgets you
want onto it (changing their properties as needed).   The container
automatically becomes a type of object which you can inherit from and can
itself become embedded into another container.   No code needed.

In regards to having to align or group controls afterwards, in other
languages, you often will throw a series of containers onto a form, setting
up their alignment (including how any controls placed within them will
align to each other), then start putting the widgets such as buttons, text
fields etc after the layout has been completed.    You can still move
widgets within each container without having to break the container (group)
apart in order to use your mouse to change a single widgets position in
regards to the rest.

Livecode has a great deal to say for itself, but, in this one area, it is
still in the stone age when it comes to modern practices.

best regards
Dalton Calford


On Thu, 11 Apr 2019 at 09:51, <hakan at exformedia.se> wrote:

> 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
>
>