Panel/Form Widget

Thu Apr 11 13:25:07 EDT 2019

Hakan mentioned this but you may have missed it. You can definitely move 
controls around inside a group without breaking it apart or going into Edit 
Group mode. On the toolbar there's an icon called Select Grouped. Toggling 
that allows you to select the whole group (as you're doing now) or select 
only the control in the group you click on. I usually keep Select Grouped 
enabled all the time, I almost never have to go into edit group mode. And 
it's never required to ungroup just to make changes.

If you want to add a control to an existing group, copy (or cut) it, ensure 
Select Grouped isn't enabled, right click on the group and choose "Paste 
into group" from the contextual menu. Then re-enable Select Grouped and 
drag the control where you want it.

The group can be set to expand automatically if you move a control out of 
bounds, or to be locked so that controls are clipped when they move too 
far. Controls in the group will always keep their relative positions, so no 
scripting is required to manage that unless you want to change it dynamically.

Groups can have visible borders and they accept special effects so you can 
make them look like 3d floating panes.

Groups know their owner (and by extension, the owner of the owner) and 
their children, and LC can give you a list of all the group's children. You 
can have groups inside of groups.

--
Jacqueline Landman Gay | jacque at hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On April 11, 2019 9:15:48 AM Dalton Calford via use-livecode 
<use-livecode at lists.runrev.com> wrote:

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