Thank you Richard and Jacquie. Yes my frustrations are making a
little too judgemental, good job this list is providing an outlet for
that!
Just to be clear, I'm not trying to resize a group. I don;t even
really want to use a group. This all started when I discovered that
my stack windows don;t fit vertically on a computer with a lower
resolution screen than the one I developed on. I looked at the
geometry manager and a couple of third party tools but they all felt
like hours of work to implement due to the hundreds of controls on the
4 or 5 cards in question, plus I got the distinct impression from
people on this list that the Geometry Manager doesn't work very well.
Someone on the list gave me the idea of grouping all the objects on
the card together and placing a scrollbar on the group so that the
user on the lower resolution screen would be able to scroll the
contents of the card. Which begs the question of why cards can't have
scrollbars but that's a different discussion. I planned to detect the
screen resolution on startup and resize the windows by script as
necessary to fit on the screen. I have no desire to resize the group
or any controls on the card. I just want the contents of the group to
be scrollable when either the user or a script resizes the window in a
way that not all of the contents of the group are visible. This is an
acceptable solution for my particular app although it may not be for
others.
I will try the lockloc property and see if that makes the group scroll.
Pete Haworth
On Dec 23, 2010, at 8:27 AM, Richard Gaskin wrote:
Peter Haworth wrote:
Thanks Jacquie. Is it so unreasonable to expect that a scrollbar
on a
group should just work? I don't have the time or the inclination to
write volumes of code to implement what should be a standard feature.
At least document what is required to make a scrollbar work.
Having been down this road when I was getting started with MC/Rev/
LiveCode, I can appreciate the frustration. Retrofitting resizing
to accommodate the variety of display we want to support takes a bit
of work, and more so if you're doing it after you've laid out your
UI rather than building the UI for resizing as you go.
Frustrating as this may be at first, I'm confident that as you spend
more time on such tasks you'll come to appreciate the flexibility
groups provide, even if the cost for that flexibility is a little
bit of your time.
Many times the automatic resizing of groups is exactly what I want,
for the group to surround my controls with its margins set as I want
them.
But other times I want the group to be resized as the stack resizes,
and thankfully I can do that by setting one property and writing one
line of code in a resizeStack handler (more on that below).
Still, as a fundamentally lazy person I'm always keen to find ways
to simplify layout tasks, so I'd be interested in learning more
about how you would envision an ideal group object to work.
It may be possible for one of us to craft a behavior script that
provides the functionality you're looking for.
How would you ideally like group objects to behave?
Datagrid scrollbars just work, I don't have to write any extra code.
...because Trevor diligently wrote more than a quarter-MB of code
for us. :)
But even then, the DG won't automatically resize itself to fit your
card. As with any group, how and when a DG is resized is up to us,
and that's a good thing because the DG is flexible enough to be used
in a nearly infinite variety of layouts.
I want a tool that allows me to concentrate on the logic of my
application
and not have to deal with the distractions of every tiny detail of
a GUI.
I think that's what we're all looking for, but there's a challenge
in providing a balance between prefab behavior and flexibility.
Ideally there would be a Make Application button in the IDE, and
whatever you want to build would be built for you with one click.
But until the engine gets the PsychicLayout property implemented
<g>, GUI designers will still have to make decisions about how
layout elements are best handled, and those decisions will require a
little code to realize them just as the rest of an app's
functionality does.
Having done this sort of work in Pascal, C, and nearly every other
xTalk ever made, I find LiveCode requires me to work at least a
little less hard to implement these decisions (sometimes a LOT less
hard; I've been following a conversation in the SuperCard forums
about implementing a Finder-like Search window with multi-row
criteria inputs, and since that tool doesn't have groups the way LC
does it's a LOT more work, even in such an otherwise-graceful tool
as SC).
As for the positioning of the scrollbar, if I I position something in
the IDE, why wouldn't it stay that way in a standalone? There's no
excuse for a GUI elemnt looking one way in the IDe and then changing
when it is saved.
In my 12 years with the engine I've seen no change between the IDE
and a standalone with regard to group positioning. I believe what
you're seeing is as Jacque explained, that re-opening a card with an
unlocked group will cause the group's rect to fit its content, just
as re-opening a card with unlocked image will resize the object to
fit its bitmap contents. You should see such resizing happening in
the IDE as well when you reopen the stack.
Set the lockLoc of the group to true and that's done.
To handle the resizing, Jacque's one-liner is the answer:
on resizestack x,y
set the rect of group "mygroup" to the rect of this cd
end resizestack
If you have nested groups in your layout it may require a little
more scripting to do what you want on resizeStack, but with LC 3.5
and later groups now get two messages that can be helpful:
preOpenControl: sent just before the object is rendered, similar to
preOpenCard, so you can do adjustments there before the user
sees it.
resizeControl: sent to other controls only when the user interactively
changes the object's rect with the pointer tool, but with groups
this is now sent whenever any script causes the group's rect to
change, allowing you to handle your resizing code directly in
the group object or within a behavior assigned to it.
Tip for those making custom controls with groups: groups also have
their own selectGroupedControls property. While it defaults to true
so it honors the global property of the same name, you can set it to
false so you can deliver custom controls whose contents can't be
modified with the pointer tool. VERY handy stuff.
--
Richard Gaskin
Fourth World
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
LiveCode Journal blog: http://LiveCodejournal.com/blog.irv
_______________________________________________
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
