Card Vertical Scrollbars

[Richard Gaskin]

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