Hi Ed,
Thanks, I follow you. I guess it doesn’t really matter, but empirically I’ve shown that it does work; the patch basically means that the Viewport/Component can survive the loss of those events (it self-corrects).
Anyhow, getting back to the existingComponentToUpdate method, and its use on mobile devices. All my ListBox implementations need to have drag-to-scroll, as they are in an app that must work as close to natively as possible on mobile. I guess that many Juce developers are in the same boat in this regard
So, just restating what I’ve learned, those of us Juce developers targeting mobile, all need to use existingComponentToUpdate such that our implementations do not delete the supplied component, and always re-uses for a given rowNumber. That is fine, but the documentation really needs to be updated to clarify that! I would also suggest that you might also want to clarify in the documentation that any/all Components returned by the app through existingComponentToUpdate are guaranteed to be deleted by the Juce framework (i.e. if used in the way you document, there is no need for the app to worry about the returned Components being leaked).
The thing that puzzles me, is that in this common use case (where to support drag on mobile, the app needs to always return a previously returned row, and therefore, the app has to have a layer of code behind every ListBox to manage things), the Juce ListBox implementation doesn’t store this data itself internally, and therefore only make calls to existingComponentToUpdate for rowNumber items that have not been previously requested. That would make app code a lot simpler. Anyhow, just my 2 cents.
Best wishes,
Pete