Card Vertical Scrollbars

[Peter Haworth]

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         |     jacque at hyperactivesw.com
> HyperActive Software           |     http://www.hyperactivesw.com
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>