setting hscroll of a field from a second card

[okk]

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.

Hi Richard, this analogy doesn't convince me yet. I can change the position of a control within my scrolled group from another card, why would this be fundamentally different than changing the scroll of that group. In both cases the card/group would need to be rendered again. Isn't the hscroll just one parameter of a control, same as the loc or blendlevel etc. any change in any of those parameters requires a re-rendering of the card.

Btw. when you change via script the position of a control that is part of a scrolled group you need to set the hscrollbar of that group to true, then change the positions of your controls within the group, then set the hscrollbar of that group back to false. Only then the change of positions is rendered correctly.

Best
Oliver

[dunbarx]

Jacque and Richard.

Makes sense. Only the rendering of the card comes last. Everything else in and of it is already in place. But then, why are some properties settable from afar, and others not. Richard had addressed this earlier, but left it that scrollbars are peculiar.

I don't think, apart from experimentation, that I have ever trapped a preWhatever message in any project.

Craig

[FourthWorld]

Something like an object rect can be located and changed with relative ease by traversing the nested object records.

Scrollbars are dependent on OS-supplied font metrics that can only be determined by fully rendering the field and its contents.

[jacque]

But then, why are some properties settable from afar, and others not.

If the change only means updating a property in the object it can be done remotely, for example changing a location only requires storing different coordinates in the object description. When the card renders, the engine draws the card based on the current property description.

But in the case of a scrollbar, the field needs to be rendered before the engine can determine how to draw the field based on the scroll position. If the field isn't on the current card that can't happen.

[okk]

Hi,
I am still not completely convinced why it would be so complicated to set the scroll from another card, I can fake it by locking the screen, go to the card, set the scroll and return to my original card. Why wouldnt the engine be able to do this in the background without triggering the opencard messages?

Best
Oliver

[FourthWorld]

Why wouldnt the engine be able to do this in the background without triggering the opencard messages?

It may be that no one considered it before. Help us understand the use case: what is the benefit to the user of scrolling a field that cannot be seen?

[kdjanz]

Why wouldn't this be done in a PreOpenCard script, when the user has gone to the card but it hasn't actually appeared on the screen yet? Why do it before the user can see what is happening? It makes more sense and is more economical to do it just before the user is about to actually see it.

Please help us to see why it needs to be done remotely.

Kelly

[jacque]

I can think of one reason why remote scrolling would be easier but it's hypothetical. Imagine you have a map image on a card and on another card the user chooses a city name. You want the map scrolled to that location when the user returns to the card. The easiest way is to set the scroll remotely from the city card. As it is now, the location must be stored somwhere so that it can be retrieved on preOpenCard.

It's not too difficult to set a global or a custom property but there's overhead, and using a property risks saving the stack in the wrong configuration.

[okk]

Hi,
in my use case I wanted to recreate the state of the app to exactly the same state as the user had left it. It is a mobile app with a lot of groups that the user can swipe left or right. Originally I set the scroll of those groups just in the preOpenCard message, but it was not so snappy. The change between cards became a bit sluggish. Therefore I wanted to set the scroll of all those groups in the OpenStack message while showing some splash screen. I can "fake" the remote scrolling by locking screen, setting a flag (to avoid triggereing OpenCard messages) and then cycle through all cards, set the scroll of the group etc. but it feels a bit like a workaround. It would seem for me like expected behaviour that I can set properties by script from anywhere in the stack. But maybe I have wrong expectations.
Best
Oliver

[FourthWorld]

Changing the state of unrendered objects is not usually a bottleneck.

I'll bet there's a way we can speed that up if we see the code.