During Run, it should not halt. Perhaps you are having multiple instances,
one of them is still in debug mode
Kumar Bibek
http://techdroid.kbeanie.com
http://www.kbeanie.com
On Fri, Apr 29, 2011 at 1:13 AM, Tobiah wrote:
> On 04/27/2011 05:11 PM, Indicator Veritatis wrote:
>
>> The Eclipse de
On 04/27/2011 05:11 PM, Indicator Veritatis wrote:
The Eclipse debugger does support multi-thread debugging, but I can't
say I am all that impressed with the support for it. When, for
example, you set a breakpoint, you have no control over which thread
is running when it hits it. Whatever thread
The Eclipse debugger does support multi-thread debugging, but I can't
say I am all that impressed with the support for it. When, for
example, you set a breakpoint, you have no control over which thread
is running when it hits it. Whatever thread is running, it will stop
when it reaches that breakpo
What you describe using F7 is fairly normal. But since single-stepping
through code is tedious, and the tedium is fruitless when you don't
have the source, I usually use Step UP instead of Step Over once I
land in Android system code. I also use breakpoints in Android more
heavily than I do in othe
On 04/27/2011 11:52 AM, dnkoutso wrote:
I think F7 is STEP INTO, which would go inside the method, even if you
do not have a breakpoint. In your case it's stepping into .class files
that you do not have the source code for them and so you see this
discrepancy. Then the call returns and you are ba
I think F7 is STEP INTO, which would go inside the method, even if you do
not have a breakpoint. In your case it's stepping into .class files that you
do not have the source code for them and so you see this discrepancy. Then
the call returns and you are back in your source.
Use F6 as it's STEP
6 matches
Mail list logo
