setting hscroll of a field from a second card

[okk]

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

[jmburnod]

Hi,
For this case i use a customprop called "uToDo" and use it at opencard if it is not empty.
Best regards
Jean-Marc

[dunbarx]

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

[FourthWorld]

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.

[dunbarx]

Richard.

So one would have to (pseudo):

Code: Select all

lock screen
push cd
navigate to card of interest
set vScroll
pop cd

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:

Code: Select all

answer the scroll of fld "X" of cd "Y"

So it can "know" the scroll property of a "foreign" field, but cannot change it. Odd.

Craig

[FourthWorld]

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

[Klaus]

...
#SchrodingersScroll

LOL!

[jacque]

I always do this kind of setup on preopencard. I wasn't aware it couldn't be done remotely.

[FourthWorld]

I always do this kind of setup on preopencard. I wasn't aware it couldn't be done remotely.

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.

[dunbarx]

I tested this way back with the "Yipes". And I wondered what other properties were similarly "disabled".

Craig

[FourthWorld]

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.

[okk]

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

[dunbarx]

Richard.

. I am for now setting the hscroll of my group in the preOpenCard handler.

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?

Craig

[jacque]

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

[FourthWorld]

Richard.

. I am for now setting the hscroll of my group in the preOpenCard handler.

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?

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.