Thanks for the help Matt! I implemented a CustomDatePicker and
CustomTimePicker, for both classes have overriden the
onInterceptTouchEvent method and works like a charm now! :)
On 16 dec, 16:47, Matt H wrote:
> Hi Dirk,
>
> I had the same problem (noticed it yesterday, too, coincidentally!).
> Th
Hi Dirk,
I had the same problem (noticed it yesterday, too, coincidentally!).
The issue is that the ScrollView is intercepting and stealing the
touch events once your finger moves outside of the Date/Time Picker
controls.
To work around this, I created sub classes of Date/TimePicker which
prevent
Then I don't know -
But what sounds strange to me is that you get lots of input (new objects,
some of them possible get discarded very quickly during transformations?
growing the heap?) and still only have a garbage collection every 90
seconds?
On Fri, Mar 13, 2009 at 7:01 PM, AlCapwn wrote:
>
>
On Mar 12, 10:35 pm, Mariano Kamp wrote:
> I vaguely remember a similar problem too. Do you also see the dreaded "You
> used the BufferedReader default constructor" (something like that) message?
> I had the feeling that it lead to a lot of garbage collections which would
> in turn explain the un
I vaguely remember a similar problem too. Do you also see the dreaded "You
used the BufferedReader default constructor" (something like that) message?
I had the feeling that it lead to a lot of garbage collections which would
in turn explain the unresponsiveness I suppose.
Btw. I got rid of the Spa
Is there any way to get around the problem of it being non responsive?
The lack of feedback to the scroll attempt is very noticeable.
On Mar 11, 11:16 pm, Romain Guy wrote:
> It's waiting for events in the main events queue. That's pretty normal
> to see this.
>
>
>
> On Wed, Mar 11, 2009 at 4:0
It's waiting for events in the main events queue. That's pretty normal
to see this.
On Wed, Mar 11, 2009 at 4:03 PM, AlCapwn wrote:
>
> Whoops, forgot to add this. When the freeze happened, I generated a
> bugreport and it says this:
>
> "main" prio=5 tid=3 TIMED_WAIT
> | group="main" sCount=1
Whoops, forgot to add this. When the freeze happened, I generated a
bugreport and it says this:
"main" prio=5 tid=3 TIMED_WAIT
| group="main" sCount=1 dsCount=0 s=0 obj=0x400103e8
| sysTid=2339 nice=0 sched=0/0 handle=-1096221588
at java.lang.Object.wait(Native Method)
- waiting on <0x1b6
8 matches
Mail list logo
