I am adding a call to a form. For that, I have to open a table.
If I run the program, I get an error that it is already open. Fine.
Where?

I add a set step on (conditionally on a messagebox). I set a
breakpoint for when
used("cftiwiz_ccli")
becomes true.

I run the program again. I answer yes to wanting step on. I
continue the code as needed. The only time the breakpoint is set off
is in the new routine!

I run the program yet again. I answer no to wanting step on.
The code blows up as it did before the debugging code was added.

I just want to find out where in the execution path the table is
being opened. Am I doing something wrong, or is this a debugger bug?

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Gene Wirchenko seemed to utter in news:7m3vc0t13crakd02t1tk1m1ujfeg0mt97v@
4ax.com:

A couple of points:

1) If I'm not sure that a table will be open before I open
it, I always check:

IF !USED("my_table")
USE my_table IN 0
ENDIF

2) When I want to find where some mysterious thing is happening
in my code, I do the following (similar to what you're doing
I think):

a) Determine a point in execution that is definitely before
the mystery happens but is only executed once (like in a
button click - not in a refresh or activate event method).

b) At that point, place a SET STEP ON

c) When the debugger appears, enter a "Break when condition is true"
breakpoint where the condition is the mystery event:

USED("my_table") = .T.

d) Resume execution of the program and wait for it to
break on the mystery event.

-- TRW
_______________________________________
My e-mail: t r w 7
@ i x . n e t c o m . c o m
_______________________________________

trw7at (AT) ixdot (DOT) netcomdotcom (Tim Witort) wrote:

[snip]

The only difference is that I have a messagebox asking whether to
set step on. Why is having the debugger running with the breakpoint
active making the program not fail on the use?

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Gene,

any activeX or event-dependant code in your app ?
The debugger works a liitle bit different in these areas...

good hunting

thomas

"Thomas Ganss" <TGanss_RemoveForRealAdress (AT) T-Online (DOT) de> wrote:

ActiveX: none at all.

Event-dependent: unavoidable. This is a GUI application. (You
probably meant something specific that is not coming through. What?)

Not so far it is not.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Gene Wirchenko seemed to utter in newsnt0d01bve2ake8j0qhssuamjbek55pt3t@
4ax.com:

Have you added something like this (without any breakpoints in place)
right before the problematic USE statement?:

WAIT "USED: "+TRANSFORM(USED("my_table")) WINDOW TIMEOUT 3

Does this show "USED: .T." in the wait window?

I'm assuming your getting an error 3 "File is un use"?

-- TRW
_______________________________________
My e-mail: t r w 7
@ i x . n e t c o m . c o m
_______________________________________

trw7at (AT) ixdot (DOT) netcomdotcom (Tim Witort) wrote:

[snip]

No, the error was that the alias is already in use.

I found the problem.

It was weird. I got "USED: .F.", the form displayed, then I got
"USED: .T." and crash. The routine was somehow being called twice!

What was happening was briging up the form was causing the first
form's active control's .valid() to fire. Since this can involve
displaying, it was calling the new routine a second time.

I tried turning off the first form's validation on entry and
turning it back on on exit, and that worked. I still have another
problem with the routine, so maybe, you will hear from me again later.
(It will be about a week. Another higher-priority item has come up.)

Thank you for the help.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Gene,
"doevents" into your code, and, depending on the setting (in/out of Window)
it causes different form behavior, causing different events stemming
from the form level - which in in step with the things you mentioned down
below.

rgds

thomas

"Thomas Ganss" <TGanss_RemoveForRealAdress (AT) T-Online (DOT) de> wrote:

[Gene Wirchenko:]
Yes. It was one of those situations. (Details are in another
post.) I hate it when the debugger does not work. Making flaky code
work without correcting it defeats the purpose of the debugger.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.