Card Vertical Scrollbars

[Peter Haworth]

Thanks Joe, you make some good points.  I haven't yet seen the  
scrolling in action so I can't make a judgement on how good or bad it  
is for the user.  Just to repeat, I'm trying to deal with resizing the  
window by script to deal with different resolution screens, not the  
user re-sizing the window.

I had a prior iteration of my app written with a different development  
product and it did indeed make use of multiple windows to display the  
data that is now all in one window.  I eventually found it more  
frustrating to keep switching between windows to see all the  
information I needed so decided to go with purring all the info in one  
window. I personally find the app easier to use that way but I think  
that's one of the difficulties in GUI design - what works for one  
person doesn't necessarily work for another.

I'll admit that the scrolling is an easy workaround to a last minute  
problem (if it works smoothly) and I may have to bite the bullet and  
deal with resizing/re-positioning all the controls to make them fit on  
the card when I resize it.

Pete Haworth

On Dec 23, 2010, at 10:51 AM, Joe Lewis Wilkins wrote:

> Pete,
>
> I'd seriously consider "reconsidering" your design concept. The  
> speed with which LC goes to new cards makes the use of scrolling  
> anything other than a text field not a very plausible solution. A  
> really good navigation concept that judiciously provides connections  
> between associated and related answers/solutions/queries makes for  
> something far more useful in an application than interminable  
> "scrolling" gobs of "things" that the user has to scrutinize in  
> order to proceed with whatever it is they are doing or trying to do.  
> A well thought-out application resolves all of these issues for the  
> user. These are decisions that you should be making "for" the user;  
> not just slapping up a lot of information/data that they have to  
> process. You should do the processing. You're the expert of your  
> application. Obviously, I'm not talking about applications designed  
> for the purpose of the user creating content. They should just be  
> providing information that allows your application to make decisions  
> for alternatives in processing; otherwise, there is no point in your  
> creating the application in the first place.
>
> Frankly, I'm also against the entire concept of allowing the  
> resizing of windows. When we were dealing with 9" and 12" screens,  
> that was obligatory. Not so now. Obviously, IMHO!
>
> Now, off of my soap-box! (smile) Good luck.
>
> Joe Lewis Wilkins
> Architect & Director of Product Development for GSI
> <www.glsysinc.com>
>
>
> On Dec 23, 2010, at 10:34 AM, J. Landman Gay wrote:
>
>> On 12/23/10 11:27 AM, Peter Haworth wrote:
>>> Thank you Richard and Jacquie. Yes my frustrations are making a  
>>> little
>>> too judgemental, good job this list is providing an outlet for that!
>>
>> Hey, that's why we're here. And there are lots of other people out  
>> there who will read these responses and find help, so you are doing  
>> a public service by asking. :)
>>
>>>
>>> Just to be clear, I'm not trying to resize a group.
>>
>> I know, not specifically, but you will have to in order to get the  
>> results you're after.
>>
>>> 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.
>>
>> It's the easiest and best solution, so you are on the right track.  
>> BTW, no operating system provides scrollable windows. What look  
>> like scrollable windows in other apps are exactly what you're  
>> implementing -- scrollable content in a fixed window.
>>
>>> 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.
>>
>> Ok, in that case it's easy. When your script resizes the window,  
>> have it also resize the group. You need to do that because the  
>> locked group (it must be locked) will not change size  
>> automatically, it has to be told to fit the window. If the group's  
>> contents exceed the group's size, the scrollbars will activate  
>> automatically. If the group is large enough to accomodate all its  
>> contents, scrollbars will disable automatically.
>>
>> The one liner I mentioned should be all you need in your own  
>> handler and/or a resizestack handler.
>>
>> -- 
>> 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
>