LiveCode Forums

I know this can't be this hard. I have a few cards with a single native scroller on each of them (iPhone 6 screen). I'd like to be able to have the user swipe between cards but can't get anything working. I've read through everything I can with old threads but....I haven't found anything that really works.
- The hScroll approach is too binary for my use. I scroll the field a bit off and get an hScroll that flips the page when I din;t want it to.
- I've tried mouseDown/mouseUp and touchStart/touchMove/touchEnd but am getting really inconsistent results. Sometimes it fires, sometoimes not... nothig I can be proud of/happy with.

I had assumed I'd be able to track mouse/touch position and react when the "swipe" got big enough.

Can I do this?
My 1st fallback is arrows (which I think I'd need for Android anyway?) but ther has to be a better way.
My next will be hand coding the behavior I want but that's definitely going to look clunky.

Is this just me? Am I being naive? stupid?

Any help would be appreciated

My 1st fallback is arrows (which I think I'd need for Android anyway?)

Android uses swiping too. I ran into the same problem a couple of years ago with a scroller over an image. I was not getting mouseUps consistently so I couldn't calculate the distance of the swipe. If I remember right, no mouseUp was sent if the end location was outside of the scroller area (which is likely when swiping quickly.) We did end up with arrows because of that.

I don't remember if I tried tracking with scrollerBeginDrag and scrollerEndDrag, but that's a possibility if you want to try it. Get the mouseloc on beginDrag and compare it to the mouseloc on endDrag and see if that works. But it may be that you won't get a scrollerEndDrag either if the swipe ends outside the scroller. If you try it, I'll be curious what you find.

There are several ways to handle this. I put together a down and dirty stack. Take a look and see if this approach will work for you. I took this from one of my existing apps so not every line of the code will apply.

Quick update:
1) Thanks for the touch code. I tend to do desktop only so forget about touch. Seems more "mobile" than mouseXXX though not sure why.
2) As long as the touch starts "outside" of the native scroller, things act as expected. This either means TouchEnd is working as expected or entering the native scroller discontinues the touch. Easy to see by checking coordinates but haven't yet. Will....
3) Starting a swipe "in" the native scroller is still a no go. Shame.

I have more testing to do and can see some options:
1) Using some combination of the hScroll of the native scroller and it's geometry to detect swipes vs scrolls
2) Using mergButton (control on "top" of scroller?) to simulate touch zones above the scroller
3) Adding a handler to the underlying field, detecting the touch and simulating a touch starting outside of the field
4) Just living with it.

For now, I'm trying to figure out how to teach the user to start the swipes at the edges of the screen....

Will add more when I have it.

That was my experience too, and I tried various things that didn't work. The culprit was the lack of a mouseUp message inside the scroller. Touch messages may be similar but I can't remember. The odd thing is that taps do work so you might want to implement taps at the left and right sides to go to the next card. We felt that wasn't intuitive enough so we went with arrows.

I also submitted a bug report about it but I can't find it now. It was a couple of years ago.

Found the bug report: https://quality.livecode.com/show_bug.cgi?id=12419 Scroll down to my entries near the end. I guess I did try the touch messages apparently. You could add comments there, it would bring the report back up to the team's attention. It's been confirmed but there's no progress on it yet.

Sorry for interrupting...

I was reading this post; this led me, somehow, to doing a search of the Dictionary with the argument "scroller".

This led me to "iosScroller". I don't really understand what it's talking about (although it does sound interesting). At the bottom of the entry, there is this:

Note: For full details of what the UIScrollViewContol is capable of, and background about it see the iOS reference document.

Please, WHAT is the "IOS reference document"??? WHERE does it exist? HOW can I get a copy???

Thanks!

Bonjour Michel,

you should poke around here a bit:
https://developer.apple.com/documentation/
And here:
https://developer.apple.com/design/huma ... ew/themes/

Get used to visit this often https://developer.apple.com/ if you want to develop and publish for iOS!


Best

Klaus

Hi Klaus.

Thank you for those great references.

Best regards.

Update....
Just to get some closure.

I was never able to get a native scrolling field to reliably detect swipes the way I wanted.
The layout of my screen does however, have enough "open space" so that users swiping from the edge of the screen (or in areas not covered by the native scroller) get the effect they expect. They learn quickly to start their swipes right at the edge of the screen. For those who don't get that, I have arrows at the top of the screen which they gravitate to very quickly if they can't get a swipe to happen right away.

Is it the best solution? No. I'd like to have the entire screen available for swipes but it works and I haven't goten too many complaints.

I have struggled with this same problem, and had to settle, as did Jim Mac, on leaving room at the edges to begin the swipe. Did I understand correctly that the bug has been reported?

I also have a problem with the vertical scroll of a native scroller after performing a find in the field. The find function works fine, but as soon as scrolling (vertically) is attempted after the find, the vScroll immediately is at zero, and the effect is that you must scroll again to the position that was found, effectively negating the usefulness of the find.

I have tried many "work arounds", including grabbing the vScroll of the field immediately after the find, and resetting the field to that value, but it still reverts, every time.

Any suggestions?

Thanks.

The problem is the lack of any messages when the swipe ends. The start and end positions are always the same, there is no mouseUp or touchEnd sent. It has to be fixed in the engine.

As a result of the bug report I linked to above, Panos opened a new one and submitted a PR. The team decided that mouse coordinates should be sent on scrollerBeginDrag and scrollerEndDrag, which is fine. But the PR wasn't merged because it didn't use local coordinates. It has stalled out there.

A comment here might bring it back to life:
https://quality.livecode.com/show_bug.cgi?id=21836

I need this too right now.

I left a comment. Thanks for directing me there!

Jim Mac wrote: ↑

Mon Jul 02, 2018 2:48 am

Update....
Just to get some closure.

I was never able to get a native scrolling field to reliably detect swipes the way I wanted.
The layout of my screen does however, have enough "open space" so that users swiping from the edge of the screen (or in areas not covered by the native scroller) get the effect they expect. They learn quickly to start their swipes right at the edge of the screen. For those who don't get that, I have arrows at the top of the screen which they gravitate to very quickly if they can't get a swipe to happen right away.

Is it the best solution? No. I'd like to have the entire screen available for swipes but it works and I haven't goten too many complaints.

Hi Jim, I'm going down the same path. Is it possible to post an example of your solution?

Thanks
Mark

jacque wrote: ↑

Wed Mar 06, 2019 6:18 pm

A comment here might bring it back to life:
https://quality.livecode.com/show_bug.cgi?id=21836

I need this too right now.

Hi Jacque, I took a look but from the bug report it didn't look like it had been resolved yet. True?

Mark