setting hscroll of a field from a second card
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
setting hscroll of a field from a second card
Hi,
is it really so that I cannot set the hscroll of a field or group located on card 1 from a button or card script located on card 2? If that is true, what is the rationale, is it a bug or a feature? The only work-around I found is to lock screen, go to card 1, set the hscroll, go back to card 2 and unlock screen. This feels a bit unnecessary? I am doing a mobile app and I have preopencard, opencard and closecard handlers, which always get triggered. I would like to avoid this. I could set a flag and exit the handlers, but I am just asking if I miss here something.
What I am trying to do is to set my app state to exactly the same state as when the user left the app. This includes also to set the scroll of different groups to the same position where they were when the user left the app. I want to do all this while my splash-screen is visible. Any suggestions?
Thanks!
Oliver
is it really so that I cannot set the hscroll of a field or group located on card 1 from a button or card script located on card 2? If that is true, what is the rationale, is it a bug or a feature? The only work-around I found is to lock screen, go to card 1, set the hscroll, go back to card 2 and unlock screen. This feels a bit unnecessary? I am doing a mobile app and I have preopencard, opencard and closecard handlers, which always get triggered. I would like to avoid this. I could set a flag and exit the handlers, but I am just asking if I miss here something.
What I am trying to do is to set my app state to exactly the same state as when the user left the app. This includes also to set the scroll of different groups to the same position where they were when the user left the app. I want to do all this while my splash-screen is visible. Any suggestions?
Thanks!
Oliver
-
- VIP Livecode Opensource Backer
- Posts: 2718
- Joined: Sat Dec 22, 2007 5:35 pm
- Location: Genève
- Contact:
Re: setting hscroll of a field from a second card
Hi,
For this case i use a customprop called "uToDo" and use it at opencard if it is not empty.
Best regards
Jean-Marc
For this case i use a customprop called "uToDo" and use it at opencard if it is not empty.
Best regards
Jean-Marc
https://alternatic.ch
-
- VIP Livecode Opensource Backer
- Posts: 9669
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: setting hscroll of a field from a second card
Yipes.
Neither the H nor V scrolls are settable remotely. Has to be a bug, or at least way outside the expected usage of LC. I wonder what else is not remotely settable.
You can always navigate everywhere and set as you go, but that would be a sad state of affairs.
Craig
Neither the H nor V scrolls are settable remotely. Has to be a bug, or at least way outside the expected usage of LC. I wonder what else is not remotely settable.
You can always navigate everywhere and set as you go, but that would be a sad state of affairs.
Craig
-
- VIP Livecode Opensource Backer
- Posts: 9838
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: setting hscroll of a field from a second card
Visible scrollbars can be set from anywhere within the LC process.
Scrollbars on cards that are not visible is an open question. I think I've done that in the past, but I can't say for sure. If not, it may be that the calculation of the scrollbar content height requires field rendering, which of course doesn't happen until the card is open.
Either way, if the card isn't open the scrollbar can't be seen, so it has no effect.
Scrollbars on cards that are not visible is an open question. I think I've done that in the past, but I can't say for sure. If not, it may be that the calculation of the scrollbar content height requires field rendering, which of course doesn't happen until the card is open.
Either way, if the card isn't open the scrollbar can't be seen, so it has no effect.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- VIP Livecode Opensource Backer
- Posts: 9669
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: setting hscroll of a field from a second card
Richard.
So one would have to (pseudo):
Doable, of course, and if this is a structural issue as you mentioned, then the only way out. But it seems odd that this property requires the card to be open, After all, LC can, without navigating:
So it can "know" the scroll property of a "foreign" field, but cannot change it. Odd.
Craig
So one would have to (pseudo):
Code: Select all
lock screen
push cd
navigate to card of interest
set vScroll
pop cd
Code: Select all
answer the scroll of fld "X" of cd "Y"
Craig
-
- VIP Livecode Opensource Backer
- Posts: 9838
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: setting hscroll of a field from a second card
I haven't yet confirmed that a field's scroll cannot be changed for a field on an unopened card. I'll try to make time for that later.
But if the card cannot be seen, how is the user affected by a change to its scroll position?
#SchrodingersScroll
But if the card cannot be seen, how is the user affected by a change to its scroll position?
#SchrodingersScroll
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- VIP Livecode Opensource Backer
- Posts: 7237
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: setting hscroll of a field from a second card
I always do this kind of setup on preopencard. I wasn't aware it couldn't be done remotely.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
-
- VIP Livecode Opensource Backer
- Posts: 9838
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: setting hscroll of a field from a second card
I don't think it is. I just made a quick test and found that attempting to set either the scroll or vscroll of a field on an unopened card has no effect.
- Attachments
-
- RemoteScrollTest.zip
- (888 Bytes) Downloaded 200 times
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- VIP Livecode Opensource Backer
- Posts: 9669
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: setting hscroll of a field from a second card
I tested this way back with the "Yipes". And I wondered what other properties were similarly "disabled".
Craig
Craig
-
- VIP Livecode Opensource Backer
- Posts: 9838
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: setting hscroll of a field from a second card
There are a small number of properties that require unpacking and initializing the entire contents of the card before the engine can alter them.
A field's scroll is among them, not too surprising if you consider all the factors in play (field rect, contents, text metrics that require rendering, etc.).
I suppose it could become possible to render the card into an offscreen buffer to set the scroll, but since that special case wouldn't be part of the normal stack rendering procedures I'm guessing it would be tedious work to implement.
That said, it may not be bad to submit a feature request for it. Just given the low impact you'd still need an alternate solution in the meantime, and many are available.
A field's scroll is among them, not too surprising if you consider all the factors in play (field rect, contents, text metrics that require rendering, etc.).
I suppose it could become possible to render the card into an offscreen buffer to set the scroll, but since that special case wouldn't be part of the normal stack rendering procedures I'm guessing it would be tedious work to implement.
That said, it may not be bad to submit a feature request for it. Just given the low impact you'd still need an alternate solution in the meantime, and many are available.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: setting hscroll of a field from a second card
Hi and thanks for the responses. I am for now setting the hscroll of my group in the preOpenCard handler. But from intuition it would seem sensible that I can set the scroll property from anywhere in the stack. Not sure I understand why it is more difficult for LC to set the scroll than for example the blendlevel from a different card or changing the location of an object.
Especially with mobile apps you have to do a lot of resizing and adjusting the UI in the preOpenStack handler, that is where I would like to reconstruct as well my app state including scrolling my fields and groups to the place where the user left the app.
This behaviour should perhaps be mentioned in the dictionary, it took me quite a while to figure out that setting the hscroll from stacklevel did not had any effect, but also did not throw any error. Follow up questions: how can I suggest additions to the dictionary and where could I file a feature request? I know how to file a bug report already.
Thanks!
Oliver
Especially with mobile apps you have to do a lot of resizing and adjusting the UI in the preOpenStack handler, that is where I would like to reconstruct as well my app state including scrolling my fields and groups to the place where the user left the app.
This behaviour should perhaps be mentioned in the dictionary, it took me quite a while to figure out that setting the hscroll from stacklevel did not had any effect, but also did not throw any error. Follow up questions: how can I suggest additions to the dictionary and where could I file a feature request? I know how to file a bug report already.
Thanks!
Oliver
-
- VIP Livecode Opensource Backer
- Posts: 9669
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: setting hscroll of a field from a second card
Richard.
Craig
Why is this enough for LC to set the scroll, since the card has not opened yet? I guess there is a difference between an as yet unopened card and a card that is not open?. I am for now setting the hscroll of my group in the preOpenCard handler.
Craig
-
- VIP Livecode Opensource Backer
- Posts: 7237
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: setting hscroll of a field from a second card
I had the same misconception for years until Mark Waddingham corrected me. The stack, background, and card are fully loaded before any of the pre* or open* messages are sent. He pointed out that if that were not the case then commands could not reference anything in the stack before you see it on screen.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
-
- VIP Livecode Opensource Backer
- Posts: 9838
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: setting hscroll of a field from a second card
Imagine getting settled into a hotel room.
You arrive with everything you have packed into a suitcase.
Later, everything is put where it's most useful: clothes hanging in the closet, personal belongings in a dresser, secure things in the safe, food in the refrigerator, etc.
Now imagine that the process of unpacking the suitcase happens while you're wearing a blindfold, and a robot is doing the actual work.
In that case, the difference between having everything in the suitcase and having everything set up and ready for use appears to be instantaneous, even though it's actually a lot of work. It's just not work you're doing, or even seeing.
The pre* messages are sent in the moment just before you take off the blindfold, after all the work of unpacking a card record and all of its control records has been done.
Attempting to alter a field property dependent on rendering the field's contents on an unopened card is like trying to iron a shirt while it's still packed into the bottom of the suitcase.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn