Hi,
I have a simple MDI application and I added the tooltip-example from the
samples directory to it. All ist running fine but if I run it in debugger
and want to invoke the debugger (pause program, I think this is similiar to
strg-S in old debugger) than allways I stop within the source of the
Tooltips program and never in the source of the main program. OK, there is a
thread window I can open and see 2 threads, one idele and one running. But
this window is no help:
1) the threads listed there have no names (they could be named by the
function that was called with start() or the list could show the function
actually running in this thread.
2) There is no possibility to choose what thread I want to debug. There is a
context menu where I can set "enabled" and "debug" but I cant se any
influence from this settings into the debugging behaviour o my application.
What for are these settings? For future things?
3) Why there is no possibility to choose the thread I want to debug from
within the threads-window just by double click or maybe over the context
menu and with this switch from the actual code line (execution point) of
thread 1 to the actual line of thread 2? This I missed in the old debugger
and here again.
I wonder why no one ever asked for this within all this years. Or did I miss
something? Or is no one working with threads?

Klemens

Klemens Lichter wrote:

> Hi,
> I have a simple MDI application and I added the tooltip-example from the
> samples directory to it. All ist running fine but if I run it in debugger
> and want to invoke the debugger (pause program, I think this is similiar to
> strg-S in old debugger) than allways I stop within the source of the
> Tooltips program and never in the source of the main program. OK, there is a
> thread window I can open and see 2 threads, one idele and one running. But
> this window is no help:

simply go to the editor and mark a line with the f5 key. There is no 
eqivalent to the ctrl-s key!! This is a new way! you can set/unset your 
breakpoint at any time even when the program is running.


> 1) the threads listed there have no names (they could be named by the
> function that was called with start() or the list could show the function
> actually running in this thread.
> 2) There is no possibility to choose what thread I want to debug. There is a
> context menu where I can set "enabled" and "debug" but I can´t se any
> influence from this settings into the debugging behaviour o my application.
> What for are these settings? For future things?

sure there is, see above. Just set a breakpoint.

> 3) Why there is no possibility to choose the thread I want to debug from
> within the threads-window just by double click or maybe over the context
> menu and with this switch from the actual code line (execution point) of
> thread 1 to the actual line of thread 2? This I missed in the old debugger
> and here again.
> I wonder why no one ever asked for this within all this years. Or did I miss
> something? Or is no one working with threads?

You missed it 


> 
> Klemens
> 
>

HI JIm,

> "James Loughner" <jwrl@charter.net> schrieb im Newsbeitrag
news:2J3K6uq4DHA.2016@S15147418...
> Klemens Lichter wrote:
>
> > Hi,
> > I have a simple MDI application and I added the tooltip-example from the
> > samples directory to it. All ist running fine but if I run it in
debugger
> > and want to invoke the debugger (pause program, I think this is similiar
to
> > strg-S in old debugger) than allways I stop within the source of the
> > Tooltips program and never in the source of the main program. OK, there
is a
> > thread window I can open and see 2 threads, one idele and one running.
But
> > this window is no help:
>
> simply go to the editor and mark a line with the f5 key. There is no
> eqivalent to the ctrl-s key!! This is a new way! you can set/unset your
> breakpoint at any time even when the program is running.

This I know, but if you use it very often you get so much breakpoints in
your code that it is not vers pleasant to run and debug you programms. But I
think "Pause" is something like an equivalent to Strg-S, it stops the
program running in debugger and you can see the current line. So far, so
good, this is not the problem, but if by accident the current execution
point is not in that thread you just want to inspect some variables you
dont have any chance to reach this thread from this point. And that is what
Im missing.

> > 1) the threads listed there have no names (they could be named by the
> > function that was called with start() or the list could show the
function
> > actually running in this thread.
> > 2) There is no possibility to choose what thread I want to debug. There
is a
> > context menu where I can set "enabled" and "debug" but I cant se any
> > influence from this settings into the debugging behaviour o my
application.
> > What for are these settings? For future things?
>
> sure there is, see above. Just set a breakpoint.

> > 3) Why there is no possibility to choose the thread I want to debug from
> > within the threads-window just by double click or maybe over the context
> > menu and with this switch from the actual code line (execution point) of
> > thread 1 to the actual line of thread 2? This I missed in the old
debugger
> > and here again.

The breakponts are not able to bring me to the current execution point
within every thread at every given situation. Only than, when the breakpoint
and the current execution point fall together. If you have for example 1000
lines of code and set maybe 10 breakpounts somewhere in this code you have a
chance of 1% to hit this and 99% to miss the situation. And also there is no
defined rule that if you pause the program you stop within the thread you
really want to inspect.  So If Alaska enables a possibility to switch to the
different current execution points of all concurrently running threads just
by selecting within the thread window you have the possibility to reach
every actual situation within the running program.

> > I wonder why no one ever asked for this within all this years. Or did I
miss
> > something? Or is no one working with threads?
>
> You missed it 

Yes, I know people working with threads, but debugging threads is not very
good implemented.

Klemens

Hi Klemens

You can clear breakpoints from the breakpoint window. Even clear all 
with a ctrl-A

Jim

Klemens Lichter wrote:
> HI JIm,
> 
> 
>>"James Loughner" <jwrl@charter.net> schrieb im Newsbeitrag
> 
> news:2J3K6uq4DHA.2016@S15147418...
> 
>>Klemens Lichter wrote:
>>
>>
>>>Hi,
>>>I have a simple MDI application and I added the tooltip-example from the
>>>samples directory to it. All ist running fine but if I run it in
> 
> debugger
> 
>>>and want to invoke the debugger (pause program, I think this is similiar
> 
> to
> 
>>>strg-S in old debugger) than allways I stop within the source of the
>>>Tooltips program and never in the source of the main program. OK, there
> 
> is a
> 
>>>thread window I can open and see 2 threads, one idele and one running.
> 
> But
> 
>>>this window is no help:
>>
>>simply go to the editor and mark a line with the f5 key. There is no
>>eqivalent to the ctrl-s key!! This is a new way! you can set/unset your
>>breakpoint at any time even when the program is running.
> 
> 
> This I know, but if you use it very often you get so much breakpoints in
> your code that it is not vers pleasant to run and debug you programms. But I
> think "Pause" is something like an equivalent to Strg-S, it stops the
> program running in debugger and you can see the current line. So far, so
> good, this is not the problem, but if by accident the current execution
> point is not in that thread you just want to inspect some variables you
> don´t have any chance to reach this thread from this point. And that is what
> I´m missing.
> 
> 
>>>1) the threads listed there have no names (they could be named by the
>>>function that was called with start() or the list could show the
> 
> function
> 
>>>actually running in this thread.
>>>2) There is no possibility to choose what thread I want to debug. There
> 
> is a
> 
>>>context menu where I can set "enabled" and "debug" but I can´t se any
>>>influence from this settings into the debugging behaviour o my
> 
> application.
> 
>>>What for are these settings? For future things?
>>
>>sure there is, see above. Just set a breakpoint.
> 
> 
>>>3) Why there is no possibility to choose the thread I want to debug from
>>>within the threads-window just by double click or maybe over the context
>>>menu and with this switch from the actual code line (execution point) of
>>>thread 1 to the actual line of thread 2? This I missed in the old
> 
> debugger
> 
>>>and here again.
> 
> 
> The breakponts are not able to bring me to the current execution point
> within every thread at every given situation. Only than, when the breakpoint
> and the current execution point fall together. If you have for example 1000
> lines of code and set maybe 10 breakpounts somewhere in this code you have a
> chance of 1% to hit this and 99% to miss the situation. And also there is no
> defined rule that if you pause the program you stop within the thread you
> really want to inspect.  So If Alaska enables a possibility to switch to the
> different current execution points of all concurrently running threads just
> by selecting within the thread window you have the possibility to reach
> every actual situation within the running program.
> 
> 
>>>I wonder why no one ever asked for this within all this years. Or did I
> 
> miss
> 
>>>something? Or is no one working with threads?
>>
>>You missed it 
> 
> 
> Yes, I know people working with threads, but debugging threads is not very
> good implemented.
> 
> Klemens
> 
>

"Klemens Lichter" <csl@lichter.de> wrote in message
news:HvucPqs4DHA.2012@S15147418...
> This I know, but if you use it very often you get so much breakpoints in
> your code that it is not vers pleasant to run and debug you programms. But
I
> think "Pause" is something like an equivalent to Strg-S, it stops the
> program running in debugger and you can see the current line. So far, so
> good, this is not the problem, but if by accident the current execution
> point is not in that thread you just want to inspect some variables you
> dont have any chance to reach this thread from this point. And that is
what
> Im missing.
>
> > > 1) the threads listed there have no names (they could be named by the
> > > function that was called with start() or the list could show the
function
> > > actually running in this thread.
> > > 2) There is no possibility to choose what thread I want to debug.
There
> is a
> > > context menu where I can set "enabled" and "debug" but I cant se any
> > > influence from this settings into the debugging behaviour o my
> application.
> > > What for are these settings? For future things?
> >
> > sure there is, see above. Just set a breakpoint.
>
> > > 3) Why there is no possibility to choose the thread I want to debug
from
> > > within the threads-window just by double click or maybe over the
context
> > > menu and with this switch from the actual code line (execution point)
of
> > > thread 1 to the actual line of thread 2? This I missed in the old
> debugger
> > > and here again.
>
> The breakponts are not able to bring me to the current execution point
> within every thread at every given situation. Only than, when the
breakpoint
> and the current execution point fall together. If you have for example
1000
> lines of code and set maybe 10 breakpounts somewhere in this code you have
a
> chance of 1% to hit this and 99% to miss the situation. And also there is
no
> defined rule that if you pause the program you stop within the thread you
> really want to inspect.  So If Alaska enables a possibility to switch to
the
> different current execution points of all concurrently running threads
just
> by selecting within the thread window you have the possibility to reach
> every actual situation within the running program.
>
> > > I wonder why no one ever asked for this within all this years. Or did
I
> miss
> > > something? Or is no one working with threads?
> >
> > You missed it 
>
> Yes, I know people working with threads, but debugging threads is not very
> good implemented.
>
> Klemens
>
>


--
---------------------------------------------------
ARD - Alaska Research & Development

Web:       http://www.alaska-research.com
Investors: http://www.alaska-research.com/tifund
E-Mail:    mailto:till.warweg@alaska-research.com
Contact:   mailto:info@alaska-research.com
---------------------------------------------------