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, <ha...@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@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
