On 12/22/10 4:29 PM, Peter Haworth wrote:
The scrollbar isn't active because everything in the group fits in the
window. So I resize the window and make it shorter - no change in the
scrollbar, still not active. OK, maybe this only works in a standalone?
Whatever you see in the stack will be the same in a standalone, so you
don't need to go to the trouble until you get it working in the stack.
The group size (and therefore its scrollbar) did't change because it
wasn't scripted to.
I make a standalone and run it. Lo and behold, the resizing of the group
I did has gone away and the scrollbar is in the wrong place. And it
still doesn't scroll.
If the group's lockloc property is false, the group will resize to fit
its content when it redraws, the same as images do. That happens on
opencard, among other things, so when you launched the standalone, it
redrew the group and adjusted the boundaries to fit. Because the
controls then fit inside it, the scrollbar didn't activate. In your
stack, adjust the group to the size you want it, and in the Size and
Position pane, lock it down. That will prevent it from resizing on redraw.
The group won't change size automatically regardless of its lockloc, it
needs instructions. The geometry manager does this in its own way, and
many of us write our own resizestack handlers to do it. Regardless of
the method you use, you need to give instructions for every control on
every card that needs to either move or change size. If your group were
the same size as the card, you'd do something like this:
on resizestack x,y
set the rect of group "mygroup" to the rect of this cd
end resizestack
But often the group and the card aren't the same size and you need to do
a little math -- get the group's rect, change the numbers in order to
inset the group's borders, or move it down, or whatever. But the idea is
to script the rectangle of the group to match the area it should cover.
The controls inside the group will not change position when the size of
their enclosing group changes. The group boundaries only define the area
where the contained controls will be visible. So you also have to alter
the object positions by script in your resizestack handler if you need
them to move.
There is no easy way to do it. The geometry manager tries to make it
simpler by automating some of the process with a GUI, but you still need
to set up every group and control individually. The Native Geometry
add-on has its own method, but you still need to show it every control.
Same for your own resizestack handler, each one needs at least a line or
two of script. It's pretty much just plain grunt work.
And that's why so many just design for the nearest common denominator
monitor size, and require that as one of the specs for the program, just
as we require a certain OS or memory footprint. But with tiny mobile
screens and giant displays now available that's harder to do than it
used to be. And even on desktops, you have to go through all that if you
want to provide a window with a resize box on the corner.
Basically there's no easy way to do it, you just roll up your sleeves
and plunge in.
--
Jacqueline Landman Gay | [email protected]
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-livecode mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
