Card Vertical Scrollbars

[Peter Haworth]

Thank you Richard and Jacquie.  Yes my frustrations are making a  
little too judgemental, good job this list is providing an outlet for  
that!

Just to be clear, I'm not trying to resize a group.  I don;t even  
really want to use a group.  This all started when I discovered that  
my stack windows don;t fit vertically on a computer with a lower  
resolution screen than the one I developed on.  I looked at the  
geometry manager and a couple of third party tools but they all felt  
like hours of work to implement due to the hundreds of controls on the  
4 or 5 cards in question, plus I got the distinct impression from  
people on this list that the Geometry Manager doesn't work very well.

Someone on the list gave me the idea of grouping all the objects on  
the card together and placing a scrollbar on the group so that the  
user on the lower resolution screen would be able to scroll the  
contents of the card.  Which begs the question of why cards can't have  
scrollbars but that's a different discussion. I planned to detect the  
screen resolution on startup and resize the windows by script as  
necessary to fit on the screen.  I have no desire to resize the group  
or any controls on the card.  I just want the contents of the group to  
be scrollable when either the user or a script resizes the window in a  
way that not all of the contents of the group are visible.  This is an  
acceptable solution for my particular app although it may not be for  
others.

I will try the lockloc property and see if that makes the group scroll.

Pete Haworth

On Dec 23, 2010, at 8:27 AM, Richard Gaskin wrote:

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