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 | [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
