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