Closed GoogleCodeExporter closed 9 years ago
Can you have a look?
Original comment by shai.almog
on 10 Apr 2012 at 6:02
I have a partial fix for this, pressing up won't move the scroll, but if you
already down pressing down again will reset to the 0 position.
Let me know if this is good enough, it is a very sensitive piece of code and I
don't want to create big changes here.
Original comment by cf27...@gmail.com
on 10 Apr 2012 at 8:19
Yes, it fixed the problem. It even worked for me for LWUIT 1.5 - I merged the
fix and some related code. Thanks a lot.
Original comment by gmi...@gmail.com
on 12 Apr 2012 at 12:15
Could you please put revisions numbers next time into issue tracker, when
closing an issue? I would help finding the changes in SVN
Original comment by gmi...@gmail.com
on 12 Apr 2012 at 12:17
We usually don't do that since committing is a separate process from closing
the bug. The revision number won't help that much since we commit major blocks
of code at once.
Original comment by shai.almog
on 12 Apr 2012 at 12:52
Please consider attached example - it has an 'invisible' component at the
bottom, because if you remove it, the last TextArea won't be seen (scroll can't
go there). The example has a problem anyway - probably something like you
mentioned, but when pressing UP key when scroll is at bottom. Also I observed
some cases when pressing DOWN key at bottom changed scroll to top.
It's probably better than it was before, but not ideal anyway. I can live with
this fix, but please consider it for general improvements. I mean that you do
not need to issue a path right away, I think it's better to rework scrolling
code later.
Frankly speaking, I was never able to get smart scrolling for BoxLayout(Y_AXIS)
in LWUIT, and some issues always remained. I think that there's some flaw in
scrolling approach which should be addressed in general way.
Original comment by gmi...@gmail.com
on 12 Apr 2012 at 3:46
Attachments:
Original issue reported on code.google.com by
gmi...@gmail.com
on 10 Apr 2012 at 5:26Attachments: