Scrollview speed limit and Scrolling abruptly stopping when adding new Elements within

@Rob

How can I increase the speed limit of the Scrollview? Doesn’t have any variable like “maxVelocity” like in Tableview?

I really need scrollview with a higher speed. (Need to be only with Scrollview, not Tableview).

I think its not so hard to implement it, is it @Rob?

And the another issue:

Scrolling stops abruptly when adding new itens to the scrollview while scrolling. (Realtime adding while Scrolling).

Is there anything that can be done to keep scrolling while adding itens in realtime?

I really really need this features.  :smiley:

Here’s the example project that shows the “Abruplty Stop” problem occurring.

Description: adding a new display object in the scrollview group every 350 milliseconds.  

Pinterest System.zip

http://www.filedropper.com/pinterestsystem

It will never happen… widgets haven’t been updated for years.  But you can download them from git and extend them.  I did this and created a scrollview that dynamically adds and removes items depending on scroll position.  This saved some 40MB texture memory.

Just download the git and then you need to remove this line (line number 440 in widget_scrollview.lua )

self:scrollToPosition( { x = origX, y = origY, time = 0 } )

Remember to change your widget requires to use your local copy and not the built in widgets library.

@adrianm 

Do you have the Link of the Scrollview GIT?

It would be possible to increase speed of the scrolling?

@adrianm @Rob

I’ve asked them to resolve an issue with the tableview some weeks ago and they resolved the question quickly. So I think they can hear our cries and resolve simple things like this ones to us. haha :)  

I find Google really useful for finding things…  search for “scrollview corona git”

Don’t need to be arrogant.

I’ve already resolved.

For the others who will read this post:

To resolve the “Abruptly Stop Issue”: Just commented the Line 439 of scrollview_widget.lua

-- self:scrollToPosition( { x = origX, y = origY, time = 0 } )

To resolve the “Scroll Speed Issue”: Just added changed the “maxVelocity” property in the library.

Cheers  :smiley:

We have in no way abandoned Widgets. As noted above we’ve have been fixing bugs.

Now that said, we have a long list of things to work on. Adding new widget features have to get scheduled in like everything else and have to originate with a feature request. There is one similar:

http://feedback.coronalabs.com/forums/188732-corona-sdk-feature-requests-feedback/suggestions/13318932-variable-scroll-speed-for-the-scrollview-widget

But as of now it has 11 votes. This can be voted up more to bring more proof that it’s something we need to add. Also as noted, we have open sourced the widgets. Many people who need custom features can make their own changes to widgets (they are after all Lua code. this is probably the most expedient way to get widget features. 

Rob

Hmm, how many people have the time to periodically go through all the suggested features and vote for them? I know I haven’t.

If a feature might be useful and would take 15 minutes to implement as variable scroll speed would, why not? Low hanging fruit and all that…

I understand there’s lots to do, but what was the rationale behind the ‘improve error messages for display.newText’ work that was done in a recent daily build, that has reportedly broken a key feature? Who requested that?

You don’t have to periodically go thru and vote on things. If you want something, go to the feedback site, search for similar requests. Find one? vote it up? Don’t find it add it then come back to the forums (in either case) and say “Hey, vote this feature up”).

This is probably low hanging fruit, but it still has to get scheduled. 

I don’t know the history behind the display.newText() fix. It could have been a bug report, or something caught in routine code scan. Anyway, that’s being looked into.

Rob

@Nick the broken newText has been fixed… Not entirely sure what “fix” involved breaking core functionality but anyway…

My point re-widgets library is entirely valid; according to the git there hasn’t been any updates for at least 2 years.  Therefore I stand by my stance (and that of others) that the widgets library hasn’t had any meaningful updates in ages and if you want to change core functionality you will need to code it yourself.

@Rob to be fair, if you guys are actively fixing widget bugs (which is great) then you really need to push those to git for developers that have decided not to wait for “fixes”.

Hi @adrianm,

Thanks for properly calling us out on this. I just made sure the open-source repo was synched up with our internal widget library. As you can see, there have been considerable updates in the past 2 years.

https://github.com/coronalabs/framework-widget

Brent

Hey Brent,

There is still a massive bug with the scrollview as per the OP and the reason I downloaded the git to amend it and that is dynamically inserting content stops the scrollview dead.

The problem is this line (removing it fixes the bug)

self:scrollToPosition( { x = origX, y = origY, time = 0 } )

in

function scrollView:updateScrollAreaSize()

called from

function scrollView:insert( arg1, arg2 )

In my case, I am adding and removing items in a large sideways scrolling view (in a similar way to how the tableview works). Loading all content added 70MB texture memory where as dynamically adding and removing only adds 8MB.

Hi @adrianm,

I’m inspecting this code you refer to. By taking out that line, have you encountered any odd side-effects with the scroll bar or other “sizing” issues as you insert objects during scrolling movement?

Brent

If you want to see the fix it is in production on my game in iTunes or Google Play.  You can see (well you can’t) content being created and destroyed on swiping.  My code will only ever render 14 buildings at any time from a much larger set.

I don’t use scroll bars so can’t comment on that aspect.

Since this is what I would call a fundamental flaw in the scrollView script, and developers are fixing it themselves, saying its a matter of a few lines of code, I’m having a hard time accepting the “we got too much to do and need you to vote for it” response.

Not all developers are on the stage that they can fix this themselves, and they are then just banging their heads against something which they cannot figure out. I have myself spend a full day trying to tweak my code, to find out what I am doing wrong to solve this behaviour.

New features are always nice to have but bugfixing existing ones should be higher priority. This is exactly the reason why I abandoned coding in Gamemaker Pro.

Hi @anaqim,

This isn’t a “vote for this” type of issue… I’m not sure where that misunderstanding came from because bug reports are not “vote to get this investigated/fixed,” while feature requests generally are.

I can likely fix this and make it official but I will need to ensure it doesn’t cause side-effects for other people who use it the “broken” way and then report to us that we “broke” it while implementing the fix you desire… after all, in some cases, one developer’s “bug” is another developer’s “the way it works” and they’re fine with that.

Best regards,

Brent

Hi Brent,

Thanks for clearing my missunderstanding up.

Perhaps this specific issue could be added as an option? That way, both camps should be covered.

Here’s the example project that shows the “Abruplty Stop” problem occurring.

Description: adding a new display object in the scrollview group every 350 milliseconds.  

Pinterest System.zip

http://www.filedropper.com/pinterestsystem

It will never happen… widgets haven’t been updated for years.  But you can download them from git and extend them.  I did this and created a scrollview that dynamically adds and removes items depending on scroll position.  This saved some 40MB texture memory.

Just download the git and then you need to remove this line (line number 440 in widget_scrollview.lua )

self:scrollToPosition( { x = origX, y = origY, time = 0 } )

Remember to change your widget requires to use your local copy and not the built in widgets library.