Alaska Software Inc. - Returning to debugger
Username: Password:
AuthorTopic: Returning to debugger
Carlos Beling Returning to debugger
on Thu, 11 Mar 2004 10:32:10 -0300
Hi all:
when you exit de debugger (<F9>) and want return to the program where 
instruction is been executed (ie: <ALT> TAB and selecting PAUSE 
PROGRAM), the debugger does nothing, unless you define one break point 
that will be performed. If the program is executing an infinit loop you 
can't know where it is.

Beling
Best regards
Technical SupportRe: Returning to debugger
on Thu, 11 Mar 2004 14:55:44 +0100
"Carlos Beling" <beling@uai.com.br> wrote in message
news:L3js802BEHA.932@S15147418...
> Hi all:
> when you exit de debugger (<F9>) and want return to the program where
> instruction is been executed (ie: <ALT> TAB and selecting PAUSE
> PROGRAM), the debugger does nothing, unless you define one break point
> that will be performed. If the program is executing an infinit loop you
> can't know where it is.

Carlos,

if I understand you correctly, you're talking about PAUSE not being
able to halt an application that is running, right? This is a current
limitation of the debugger kernel. The debugger just can't stop an
application currently executing operating or runtime system kernel
code (i.e. C/C++ or assembler code). For PAUSE to take effect,
the application must execute Xbase++ code. Therefore, if the
.EXE happens to perform a READ or if it is waiting AppEvent(),
for example, you'll have to enter a key or move the mouse so your
application leaves its wait state.

This is something we need to address in the future, of course.

Regards,
  Till

PS. I've been addressing you with "Carlos", is this correct?
I've noticed you're signing off with "Beling". I'm sorry if
I used the wrong one.

--
---------------------------------------------------
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
---------------------------------------------------
Carlos Beling Re: Returning to debugger
on Thu, 11 Mar 2004 11:25:00 -0300
Hi Till:
I did:
. built the .EXE
. run Debug ....EXE without breakpoints
. selected "Pause Program"
. typed <F8>
. the debugger stops with the message; _Error executing debugger 
command. The client does not respond! ..._
. I typed ignore and the debugger started executing the event loop.

Does it have a way for knowing the ProcName() and ProcLine() that the 
debugger is running?

Beling
Regards


Technical Support wrote:

> "Carlos Beling" <beling@uai.com.br> wrote in message
> news:L3js802BEHA.932@S15147418...
> 
>>Hi all:
>>when you exit de debugger (<F9>) and want return to the program where
>>instruction is been executed (ie: <ALT> TAB and selecting PAUSE
>>PROGRAM), the debugger does nothing, unless you define one break point
>>that will be performed. If the program is executing an infinit loop you
>>can't know where it is.
> 
> 
> Carlos,
> 
> if I understand you correctly, you're talking about PAUSE not being
> able to halt an application that is running, right? This is a current
> limitation of the debugger kernel. The debugger just can't stop an
> application currently executing operating or runtime system kernel
> code (i.e. C/C++ or assembler code). For PAUSE to take effect,
> the application must execute Xbase++ code. Therefore, if the
> .EXE happens to perform a READ or if it is waiting AppEvent(),
> for example, you'll have to enter a key or move the mouse so your
> application leaves its wait state.
> 
> This is something we need to address in the future, of course.
> 
> Regards,
>   Till
> 
> PS. I've been addressing you with "Carlos", is this correct?
> I've noticed you're signing off with "Beling". I'm sorry if
> I used the wrong one.
> 
> --
> ---------------------------------------------------
> 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
> ---------------------------------------------------
> 
> 
>
Till WarwegRe: Returning to debugger
on Mon, 15 Mar 2004 15:11:51 +0100
"Carlos Beling" <beling@uai.com.br> wrote in message
news:t6qyeS3BEHA.2808@S15147418...
> Hi Till:
> I did:
> . built the .EXE
> . run Debug ....EXE without breakpoints
> . selected "Pause Program"
> . typed <F8>
> . the debugger stops with the message; _Error executing debugger
> command. The client does not respond! ..._
> . I typed ignore and the debugger started executing the event loop.

Okay, so your application probably was sitting in AppEvent()
when you selected "Pause". That's what I meant in my last post.

>
> Does it have a way for knowing the ProcName() and ProcLine() that the
> debugger is running?

Yes, it could evaluate the very same functions. But only if it isn't
currently executing kernel code, such as AppEvent().

--
Regards,
  Till Warweg
  [Alaska Software]

--------------------------------------------------------------------
Technical Support:         support@alaska-software.com
News Server:                 news.alaska-software.com
Homepage:                     http://www.alaska-software.com
WebKnowledgeBase:    http://www.alaska-software.com/kb
--------------------------------------------------------------------
Carlos Beling Re: Returning to debugger
on Mon, 15 Mar 2004 12:00:18 -0300
Hi Till:
many thanks.

Beling
Regards

Till Warweg wrote:
> "Carlos Beling" <beling@uai.com.br> wrote in message
> news:t6qyeS3BEHA.2808@S15147418...
> 
>>Hi Till:
>>I did:
>>. built the .EXE
>>. run Debug ....EXE without breakpoints
>>. selected "Pause Program"
>>. typed <F8>
>>. the debugger stops with the message; _Error executing debugger
>>command. The client does not respond! ..._
>>. I typed ignore and the debugger started executing the event loop.
> 
> 
> Okay, so your application probably was sitting in AppEvent()
> when you selected "Pause". That's what I meant in my last post.
> 
> 
>>Does it have a way for knowing the ProcName() and ProcLine() that the
>>debugger is running?
> 
> 
> Yes, it could evaluate the very same functions. But only if it isn't
> currently executing kernel code, such as AppEvent().
> 
> --
> Regards,
>   Till Warweg
>   [Alaska Software]
> 
> --------------------------------------------------------------------
> Technical Support:         support@alaska-software.com
> News Server:                 news.alaska-software.com
> Homepage:                     http://www.alaska-software.com
> WebKnowledgeBase:    http://www.alaska-software.com/kb
> --------------------------------------------------------------------
> 
> 
>
Alex BlankendaalRe: Returning to debugger
on Mon, 17 Jan 2005 11:26:02 +0100
"Carlos Beling" <beling@uai.com.br> schreef in bericht 
news:L3js802BEHA.932@S15147418...
> Hi all:
> when you exit de debugger (<F9>) and want return to the program where 
> instruction is been executed (ie: <ALT> TAB and selecting PAUSE PROGRAM), 
> the debugger does nothing, unless you define one break point that will be 
> performed. If the program is executing an infinit loop you can't know 
> where it is.
>
> Beling
> Best regards
>
politicallyincorrect Re: Returning to debugger
on Mon, 17 Jan 2005 20:04:52 -0700
I dont agree with you, in an "infinite loop" ask vx to pause, answer 
ignore, in a loop, the debugger will stop at the next executable line, 
if it is a read event the first key command out of the read, will halt 
the event, use call stack to see were you were, once you know place 
altd()in side either the loop or out side the read and step through. wal 
la....

kurt
software by khg

Alex Blankendaal wrote:
> "Carlos Beling" <beling@uai.com.br> schreef in bericht 
> news:L3js802BEHA.932@S15147418...
> 
>>Hi all:
>>when you exit de debugger (<F9>) and want return to the program where 
>>instruction is been executed (ie: <ALT> TAB and selecting PAUSE PROGRAM), 
>>the debugger does nothing, unless you define one break point that will be 
>>performed. If the program is executing an infinit loop you can't know 
>>where it is.
>>
>>Beling
>>Best regards
>>
> 
> 
>