Card Vertical Scrollbars

[J. Landman Gay]

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         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com