Mobile scrolling problem

[glenn9]

I've starting to dip my toe a little into mobile and have tried to set up a little notes app with a list of contents in a scrolling list field on Card A, and when an item is tapped, leads to the relevant information in a scrolling list field on Card B.

So far so good, with the help of the forum I've worked out how to code the difference between a scroll and a tap and I can get the fields scrolling on mobile to a degree, but here lies my problem...

If after arriving at the information field on Card B I then navigate back to the contents field on Card A, the Card A scrolling list field seems to 'break', ie no longer scrolls correctly on mobile.

I've used the same basic code on both fields of both cards, and indeed the scrolling works correctly on Card A initially, and its only when I return to Card A from Card B that the scroller on Card A no longer works.

I've tried putting Card B in a substack but this doesn't solve the problem.

Just wanted to check if I was missing something...?

Have attached the stack if it helps.

Many thanks for any advice.

Kind regards,

Glenn

[SparkOut]

Hi Glen, unless things have changed substantially since I last did this, you have to delete the scroller on closing the card (navigating away from Card A) and recreate it again in the openCard script (or preOpenCard maybe, but I think that might possibly not work properly as the layout isn't fully rendered at that time).
The native controls are created at dynamically and persist in their own layer until destroyed, so card B will retain the scroller from card A if you don't remove it in the close script (of card A). This could cause lots of GUI problems.
You may also want to preserve the current vScroll value in the close script and when opening again, reset the vScroll to zero on card A, then apply the scroller and finally set the vScroll of the LiveCode objects AND the native scroller to match. (Or otherwise set the vScroll of both to zero when opening the card again, otherwise the scroll position will be off.)

[glenn9]

Thanks SparkOut,

it makes sense what you say but can I ask, I'm not sure I understand how to remove a handler, or what a 'close script' entails - I've not come across either of these concepts before?

Regards,

Glenn

[SparkOut]

In the same way that you have a handler that deals with the openCard message, you have one for closeCard (and equivalent messages/handlers for openStack and closeStack, etc).
When you leave a card and navigate to a new one, the closeCard script will be triggered. Put commands in there to destroy the scroller on that card, so that it will not interfere on the next card. When you looked up mobileControlCreate in the dictionary, did you notice the "related" section, and see how to use mobileControlDelete?

[glenn9]

Hi SparkOut,

Many thanks, I'd not appreciated the mobileControlDelete command and why it was needed... I'll now try and build it into my script.

Thank you again,

Kind regards,

Glenn

[glenn9]

Hmmm... after adding the mobileControlDelete as a function on the card, both cards stop scrolling once having been navigated away from, ie the mobileControlDelete seems to be doing its job...

Not sure why the 'opencard' command isn't recreating the scroller dynamically when a card is navigated to though?

Just out of interest I put a button on both cards and copied the mobileControlCreate script into the script of these buttons... and lo and hehold when I fire the button the scroller starts working again...!

It almost seems to me that even though a card 'opens' on being navigated to, the associated opencard function doesn't fire...

However, firing the button, which has the same code in as the opencard function, does allow the scroller to work again.

I'm confused...!

[jacque]

Where is the opencard handler located? It sounds like it is either not in the message path or is being blocked somehow. If you add

Code: Select all

answer "opencard fired"

to the opencard handler, does that run?

[glenn9]

By coincidence I've just tried that as well - it doesn't fire when I navigate to Card A, its as if the opencard handler hasn't been called...

I think click on a button with same code as the opencard handler and the scroller works again!

[glenn9]

apologies, the opencard handler is on the card script

[jacque]

Well, that's a puzzle. Something is blocking the openCard handler. Do you use any frontscripts? Do you (accidentally) have two openCard handlers in the card script? Only the first one will run.

Creating mobile controls does work on preOpenCard so you could try it there instead, but it would be better to figure out where the message is being blocked to avoid any other issues later.

[glenn9]

Thank you so much to those tips. I'll go through my code again to see if I can spot where the issue is. Many thanks again.

[glenn9]

SparkOut, Jacque, thank you for all the pointers etc, these were a great help and gave me lots of food for thought resulting in everything now working as expected!

What seems to have solved it was adding the mobileControlDelete command and moving Card B to the same stack as Card A (it was previously in a substack as a trial and error (more error!) measure). I'm assuming that not having Card A and B on the same stack was interfering with the message path in someway?

Kind regards,

Glenn

[jacque]

Aha, that explains it. I ran into the same problem once. If a stack has already been opened and is just idling in the background behind another stack, no open* messages are sent because the stack is already open. If the card hasn't changed, you don't get an opencard message either.

Your fix is the easiest. If the card was changed in the background and then navigated to the original card when the stack was brought to the front, you'd probably get the message. But that would be really ugly.

Trapping resumeStack might work.