Hi Brent!
We really need some informations about this correction. Please keep us informed.
Hi all,
For those with Starter accounts, I’ve been told that a new public release is drawing closer, but I still don’t know a specific day. We’re addressing several things in this upcoming release, not just this. For Pro users, this bug has been fixed since several daily builds back.
Your patience is greatly appreciated, and we’re getting there as fast as we can.
Take care,
Brent
Totally agree…!
For anyone who doesn’t have a subscription to get the daily build with the fix, I hacked out a quick fix in the meantime:
local isBegan = true local scrollTimer -- ScrollView listener local function scrollListener( event ) if(scrollTimer~=nil)then timer.cancel(scrollTimer) end if(isBegan==true)then print("Phase Began") isBegan = false else print("Phase Moved") end local function phaseEnded() print("Phase Ended") isBegan = true end scrollTimer=timer.performWithDelay(150,phaseEnded,1) end
If it’s a slow swipe, the began phase might be called multiple times…if this is happening, increase the timer from 150 to 200 or 300. Tweak around a bit, and you should get it good enough for the moment!
Seems like this issue is still there in the most recent G2 release (ie #2076) as well.
I’ve experienced the same behavior and filed it as a bug yesterday afternoon (Case 28117) before seeing this post. No response from Corona yet.
There hasn’t been a daily build since November 13, so it hasn’t been fixed yet.
I just noticed there’s a discussion of the same bug here as well:
http://forums.coronalabs.com/topic/41531-eventphase-not-detected-in-scrolllistener-of-scrollview/
FYI, there’s Yet Another Thread (this one is in the daily builds section) noting this bug as well:
http://forums.coronalabs.com/topic/41361-daily-build-1260-broke-scrollview-listeners/
The more buzz we make the higher it will be on their priority list (i hope) 
any reaction on the bug report?
Bram
Alas, I haven’t received a response to my bug report yesterday re: scrollview event.phase, which I’ve also mentioned in an aside in email to Walter (he had asked me via email for more detail regarding an unrelated webview bug).
There’s another bug filed around the same time as mine on the same topic, according to the daily build thread. That bug is Case 28111.
I suppose I could regress to an earlier daily build – maybe pre-1260 – but there seems to have been a reasonable amount of surgery performed on the scrollview for build 1260 and I’d rather only have to work on this part of the code once and then leave it alone.
Good to hear!
Is there an estimate on when the fix wil be implemented?
Thanks,
Bram
Thanks, Brent. Though a more precise estimate on the fix time would, as Bram said, be useful. The latest release came out approximately a week ago, and bug reports on this problem were filed days ago.
Can you give us a hint? Will it be this week?
Hi all, it should be this week, but it’s sort of “out of my hands” at this stage. I believe it’s being tested a.t.m.
Thanks,
Brent
So daily build 2013.2082 came out today, and there’s no mention of the scrollview bug being fixed:
http://developer.coronalabs.com/release/2013/2082/
I’m monitoring this, and it appears that it’ll come in the next release (not 2082, but next one after that). Thanks for your patience everybody.
Brent
I presume for the rest of us who don’t have access to daily builds we will be left stranded with a buggy G2.0 release then?
Ow snap! That is indeed a big issue,
wil the basic/starter users get a chance to work with a proper working G.2 release?
I’ve been informed that we’ll probably be releasing a new public build (2.0-based) with this and other fixes implemented. I don’t have an ETA on that yet, but it shouldn’t be too far off.
Best regards,
Brent
Ah that’s good news!
When there is a estimate, would you be so kind to let us know?
Thanks,
Bram