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. Datagrid
scrollbars just work, I don't have to write any extra code. 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.
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.
Pete Haworth
On Dec 22, 2010, at 7:36 PM, J. Landman Gay wrote:
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
_______________________________________________
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
