Hi

As reported in the programming ng (and I hasten to report here as there
is dBI activity here today!) the debugger is not working in v2.5.

Save this code to a file and run it in v2.5. On my system the debugger
window starts to open but is empty and immovable and frozen. Closing
it causes the OS to say the debugger is not responding. Then the code
proceeds. It works fine in b.1755.

x = 1
set step on
x = 2
msgbox("You should only reach this by following debugger steps.", "", 48)
x = 3
return

Bruce Beacham

From:	Andrew Shimmin
Subject:	Re: Debugger
Date:	Thu, 20 Jan 2005 18:30:11 +1100

Bruce's code runs with no problem on my main development machine and my notebook.

Development machine is XP Pro Sp2 with all hotfixes. dBPlus build 1804.
Notebook is XP Pro SP2 with all hotfixes. dBPlus build 1755.

However, I have noticed the debugger GPF on many occasions while debugging a large application.

andrew

Bruce Beacham wrote:
> Hi
>
> As reported in the programming ng (and I hasten to report here as there
> is dBI activity here today!) the debugger is not working in v2.5.
>
> Save this code to a file and run it in v2.5. On my system the debugger
> window starts to open but is empty and immovable and frozen. Closing
> it causes the OS to say the debugger is not responding. Then the code
> proceeds. It works fine in b.1755.
>
> x = 1
> set step on
> x = 2
> msgbox("You should only reach this by following debugger steps.", "", 48)
> x = 3
> return
>
>
> Bruce Beacham

From:	Bruce Beacham
Subject:	Re: Debugger
Date:	Thu, 20 Jan 2005 08:29:02 +0000

> Bruce's code runs with no problem on my main development machine and my
> notebook.

How do you call it?

> However, I have noticed the debugger GPF on many occasions while
> debugging a large application.

I find it fine except when called from a report.render() method. Then
it is prone to throw internal errors.

Bruce

From:	Andrew Shimmin
Subject:	Re: Debugger
Date:	Thu, 20 Jan 2005 19:42:21 +1100

> How do you call it?

I just ran it from the IDE and the debugger opened on the SET STEP ON. Then I ran it from the debugger itself. Both worked fine.

> I find it fine except when called from a report.render() method. Then
> it is prone to throw internal errors.

I have never really bothered to figure it out since I have had debugger problems from dB2K. I just reload. Trying to reproduce the problem is a pointless exercise from my perspective. I have wondered if I should send all the GPF reports to M$ just to annoy them.

andrew

From:	Bruce Beacham
Subject:	Re: Debugger
Date:	Thu, 20 Jan 2005 11:05:16 +0000

Andrew Shimmin wrote:
>> How do you call it?

> I just ran it from the IDE and the debugger opened on the SET STEP ON.
> Then I ran it from the debugger itself. Both worked fine.

OK. At the command prompt in the IDE do you issue
savedprg()

- or

do savedprg

The latter seems to be more likely to provoke the error.

>
>> I find it fine except when called from a report.render() method.
>> Then it is prone to throw internal errors.
>
>
> I have never really bothered to figure it out since I have had debugger
> problems from dB2K. I just reload. Trying to reproduce the problem is a
> pointless exercise from my perspective. I have wondered if I should send
> all the GPF reports to M$ just to annoy them.

Hmm, GPF reports arising in a competing product (dBASE) would delight them!

Bruce

From:	Andrew Shimmin
Subject:	Re: Debugger
Date:	Thu, 20 Jan 2005 22:48:47 +1100

> OK. At the command prompt in the IDE do you issue
> savedprg()
>
> - or
>
> do savedprg
>
>
> The latter seems to be more likely to provoke the error.

I actually used the popUp menu in the navigator an then "Run Program" or "Debug".

However I tried your way from the command window and "saveprg()" works fine ... "do saveprg" produces the bug like you said. Lucky I never code "do someprg".

andrew

From:	Bruce Beacham
Subject:	Re: Debugger
Date:	Thu, 20 Jan 2005 15:13:28 +0000

Andrew Shimmin wrote:
>> OK. At the command prompt in the IDE do you issue
>> savedprg()
>>
>> - or
>>
>> do savedprg
>>
>>
>> The latter seems to be more likely to provoke the error.
>
>
> I actually used the popUp menu in the navigator an then "Run Program" or
> "Debug".
>
> However I tried your way from the command window and "saveprg()" works
> fine ... "do saveprg" produces the bug like you said. Lucky I never code
> "do someprg".

Well, that's for testing purposes, but it's nice to have the issue
confirmed!

Bruce

From:	Marty Kay
Subject:	Re: Debugger
Date:	Wed, 19 Jan 2005 15:27:11 -0500

Hi Bruce,

I'm not seeing this behavior.

Using Win XP SP1
On both dBASE Plus b1804 and b1807
debugger runs properly - no lockups and no crashes

On our latest inhouse build b1823
It worked correctly, 8 times out of 9.

On the 4th time running under this build both the dBASE Plus window
and the debugger window's client area were painted all white.
However, the dBASE Plus application icon in the Windows taskbar was
flashing.
When I clicked on it, the msgbox() from your test program was
displaying.
Once I clicked on OK in the msgbox() to clear it, the debugger window
remained empty,
so I clicked its close button to close it. I received the windows
dialog saying that the application
was not responding, End Now? I clicked yes.

Next, when I restarted dBASE Plus and again ran your test program,
everything worked correctly.

So, I agree there are some debugger *bugs* to fix, however, they are not
so easy to reproduce.

Please check whether or not the PlusDebug.exe you are testing with is from
the same build as your Plus.exe.

Thanks,

- Marty Kay (dBI) -

"Bruce Beacham" wrote in message
news:zJoskwZ$EHA.1128@news-server...
> Hi
>
> As reported in the programming ng (and I hasten to report here as there
> is dBI activity here today!) the debugger is not working in v2.5.
>
> Save this code to a file and run it in v2.5. On my system the debugger
> window starts to open but is empty and immovable and frozen. Closing
> it causes the OS to say the debugger is not responding. Then the code
> proceeds. It works fine in b.1755.
>
> x = 1
> set step on
> x = 2
> msgbox("You should only reach this by following debugger steps.", "", 48)
> x = 3
> return
>
>
> Bruce Beacham

From:	Brian Johnson
Subject:	Re: Debugger
Date:	Thu, 20 Jan 2005 06:41:21 -0000

Marty

I am using win 2000 pro with service pack 3. dBASE PLUS 2.5 version b1804
dated 21/11/2004. The version of the debugger I can not find but
PlusDebug.exe is dated 21/11/2004. I therefore assume they are the same
build.

Running Bruce's program (with a double left click from the file name on the
navigator) the debugger immediately locks up in a maximised screen which
comprises of a grey background with a title bar but everything apparently
frozen. The only way I have found to close it is my using the task manager.

I have just deleted the debug ini file to see if that helps but the only
change is that the screen is no longer maximized.

If I right click on the file name and choose debug then it works fine but
this is not much use if you are trying to debug deep inside a complex
program.

The 'set step on' seems to cause the problem when used from within a running
program.

Brian Johnson

From:	Bruce Beacham
Subject:	Re: Debugger
Date:	Wed, 19 Jan 2005 22:22:18 +0000

Hi Marty

> I'm not seeing this behavior.
>
> Using Win XP SP1

I'm using SP2.

> On both dBASE Plus b1804 and b1807
> debugger runs properly - no lockups and no crashes
>
> On our latest inhouse build b1823
> It worked correctly, 8 times out of 9.
>
> On the 4th time running under this build both the dBASE Plus window
> and the debugger window's client area were painted all white.
> However, the dBASE Plus application icon in the Windows taskbar was
> flashing.
> When I clicked on it, the msgbox() from your test program was
> displaying.
> Once I clicked on OK in the msgbox() to clear it, the debugger window
> remained empty,
> so I clicked its close button to close it. I received the windows
> dialog saying that the application
> was not responding, End Now? I clicked yes.
>
> Next, when I restarted dBASE Plus and again ran your test program,
> everything worked correctly.
>
> So, I agree there are some debugger *bugs* to fix, however, they are not
> so easy to reproduce.
>
>
> Please check whether or not the PlusDebug.exe you are testing with is from
> the same build as your Plus.exe.

Both dated 21/11/04 16:48, installed using the defaults IIRC (in a
directory called Plus25).

The Plusdebug being run from within dBASE v2.5 is that one, I'm sure,
because it opens in a pane whereas in my other two installations (b.1712
and b.1755) it is set to maximised.

Two other people have reported it (see Brian Johnson's post 18 January
in the programming ng).

Tonight I find that it does work properly if you invoke the program with
tbg()

BUT it fails if you invoke the program with
do tbg

Bruce

From:	Marty Kay
Subject:	Re: Debugger
Date:	Thu, 20 Jan 2005 12:15:12 -0500

Bruce,

> Tonight I find that it does work properly if you invoke the program with
> tbg()
>
> BUT it fails if you invoke the program with
> do tbg

If I maximize the debugger window and close it and then run your program
via:
do tbg

I can reproduce the lockup and I've created QAID: 5164 for this bug.

As a workaround, unmaximize your debugger window.

Thanks,

- Marty Kay (dBI) -

From:	Brian Johnson
Subject:	Re: Debugger
Date:	Fri, 21 Jan 2005 10:22:30 -0000

Hi

I have elaborated Bruce's test a little by placing it in a form to try to
see if there is any way I could use your combined findings to give me a
workaround. Firstly I agree that in my test o/s, win2000 pro service pack
3, having a maximised debugger window causes a freeze up but having it
unmaximized does allow certain functions to work in programs.

All I have done is to go one level down and placed the 'set step on' in a
pushbutton onClick function as it is normally from a form, usually deep
within a program, that I call the debugger.

The test I have done from the command widow are :
do tdb.wfm with true Result debugger works as expected
do tdb.wfm Result debugger freezes

Assuming these results are duplicated in Win XP it really means that the
debugger has a very limited application at present.

Brian Johnson

Watch for word wrap.

** END HEADER -- do not remove this line
//
// Generated on 21/01/2005
//
parameter bModal
local f
f = new tdbForm()
if (bModal)
f.mdi = false // ensure not MDI
f.readModal()
else
f.open()
endif

class tdbForm of FORM
with (this)
height = 16.0
left = 71.0
top = 0.0
width = 40.0
text = ""
endwith

this.PUSHBUTTON1 = new PUSHBUTTON(this)
with (this.PUSHBUTTON1)
onClick = class::PUSHBUTTON1_ONCLICK
height = 1.0909
left = 10.7143
top = 5.1818
width = 15.2857
text = "Start debugger"
endwith

function PUSHBUTTON1_onClick
x = 1
set step on
x = 2
msgbox("You should only reach this by following debugger steps.",
"",48)
x = 3
return

endclass
// end of form

From:	Brian Johnson
Subject:	Re: Debugger
Date:	Sat, 22 Jan 2005 10:11:33 -0000

Hi
Debugger workaround

On my m/c this method of using the debugger seems to work everytime even if
you have the debugger maximized.

1. Write in the normal 'set step on' wherever in the program you need the
debugger.
2. Right click on the starting file of your program and select debug. Left
click to run.
3. Click on the 'yellow lightning strike' button to run the program at full
speed.
4. Run your program normally and when it hits the 'set step on' focus comes
back to the debugger at the appropriate line.

m/c is win 2000 pro service pack 3. If anyone else can confirm that this
works, then in my view, this goes lower down the priority scale

Brian Johnson

From:	Bruce Beacham
Subject:	Re: Debugger
Date:	Thu, 20 Jan 2005 18:36:47 +0000

> If I maximize the debugger window and close it and then run your program
> via:
> do tbg
>
> I can reproduce the lockup and I've created QAID: 5164 for this bug.

Thanks. Pretty urgent, I'd say - it's so important for development.

> As a workaround, unmaximize your debugger window.

It's not maximised at the moment! (See my comment earlier about how I
know it's the correct debugger)

Maybe it's different this side of the Atlantic!

Bruce

From:	Brian Johnson
Subject:	Re: Debugger
Date:	Wed, 19 Jan 2005 07:57:07 -0000

Marty

Hope you read this.

You will have noted that the debugger in 2.5 is not working from the 'set
step on' command within a program.
I have spent all night sorting out a bug using msgbox()'s and ? of parts of
the program.
With the debugger working I would have expected to sort the problem in my
code in less than half an hour. Instead it has taken me 12 hours when I
should have been sleeping. My apologies for a relatively bad tempered
message but suffering from sleep deprivation The debugger is not an
important part of the program until you need to use it. Then it is _vital_.
Just trying to emphasize that this is an important bug.

Good Night

Brian Johnson

From:	Bruce Beacham
Subject:	Re: Debugger
Date:	Wed, 19 Jan 2005 09:11:50 +0000

Hi Brian

> You will have noted that the debugger in 2.5 is not working from the 'set
> step on' command within a program.
> I have spent all night sorting out a bug using msgbox()'s and ? of parts of
> the program.

Unless it's code which uses features new in v2.5, it might well be
possible to run development code in an earlier version (like 2.21
b.1755) so as to have access to a working debugger - on a very temporary
basis.

That's no consolation after a lost night's sleep, of course.

Bruce