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
