How to track down 3075 error "Unknown"

[MLH]

Is it a common occurrence for A97 VBA to 'RACE' on past
a debug.print statement?

I have been trying to debug a problem (which turned out to
be an attempt to assign Null to a Date Type variable) and had
several debug.print statements...

10 Good code...
20 Debug.Print "tblBlahBlah", MyVar
30 Good code...
40 Debug.Print "tblBlahBlah", MyVar
50 Good code...
60 Debug.Print "tblBlahBlah", MyVar
70 Good code...
80 Debug.Print "tblBlahBlah", MyVar
90 Bad code...

The above illustrates the situation. I have the erroneous line of code
in Line #90. About 1/3 of the time, lines 20/40/60/80 result in some-
thing really showing up in the immediate window by the time the bad
code in Line #90 is trapped and the error msg displayed - and about
2/3 of the time it does not. It seems as if there's a RACE between VBA
running successive lines and the debug.print statement actually
writing to the immediate window.

time

[Lyle Fairfield]

You can change this setting by going to:
Tools -> Options -> International -> General Alignment -> Racist

[Thelma Lubkin]

MLH <CR**@NorthState.net> wrote:
: I have been trying to debug a problem (which turned out to
: be an attempt to assign Null to a Date Type variable) and had
: several debug.print statements...

: 10 Good code...
: 20 Debug.Print "tblBlahBlah", MyVar
: 30 Good code...
: 40 Debug.Print "tblBlahBlah", MyVar
: 50 Good code...
: 60 Debug.Print "tblBlahBlah", MyVar
: 70 Good code...
: 80 Debug.Print "tblBlahBlah", MyVar
: 90 Bad code...

: The above illustrates the situation. I have the erroneous line of code
: in Line #90. About 1/3 of the time, lines 20/40/60/80 result in some-
: thing really showing up in the immediate window by the time the bad
: code in Line #90 is trapped and the error msg displayed - and about
: 2/3 of the time it does not. It seems as if there's a RACE between VBA
: running successive lines and the debug.print statement actually
: writing to the immediate window.

What happen if you single step the code in that region?
I like seeing my debug prints show up one by one.
: time

[MLH]

very helpful

[MLH]

I don't know. I got tired of screwing with it. The age-old fallback
for me has always been MsgBox. I give up the ability to select &
copy the output, but it never fails to show up.

What happen if you single step the code in that region?
I like seeing my debug prints show up one by one.
: time

[Tim Marshall]

MLH wrote:

The above illustrates the situation. I have the erroneous line of code
in Line #90.

Just set a breakpoint at line 10 and step through it. To set a break
point, put your cursor on the line and Menu Debug->Toggle Breakpoint or
press F9 or simply click in the grey vertical bar on the line where you
want the code to stop. When you run your code, the code will suspend
itself at the breakpoint. You can then press F8 to advance one line at
a time. Holding your mouse over variables while the code is in suspense
will give you what the variable currently is and/or, in the immediate
window (ctrl-G) you can type a question mark and a variable from the
procedure to get the value:

?intMyInteger
1244

OR, possibly even better, you can view the locals window (View->Locals
Window) which will list all objects associated with the procedure.

Armed with the above, and stepping through your code (F8) you will find
what your issue is with the bad code.

Now, answer me a question! 8) How are you numbering code lines? Or do
you just do that when you copy code to a usenet post to help you
identify lines when you're discussing code? TIA.

--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "What's UP, Dittoooooo?" - Ditto

[Lyle Fairfield]

I'm glad you found it so.
I try to apply the
quid pro quo
concept when answering questions.

[Tom van Stiphout]

On Sun, 27 Nov 2005 09:41:43 -0500, MLH <CR**@NorthState.net> wrote:

It does NOT work like that.
VBA, and all other languages I know of, execute code in one procedure
("stack frame") sequentially, NOT in some multi-threaded way.
In your example, a Debug.Print line would execute BEFORE the next line
executes. Just think about the consequences if that were not the case.
x=4
x=5
Msgbox x 'Crap shoot if this displays 4 or 5.

-Tom.

Is it a common occurrence for A97 VBA to 'RACE' on past
a debug.print statement?

I have been trying to debug a problem (which turned out to
be an attempt to assign Null to a Date Type variable) and had
several debug.print statements...

10 Good code...
20 Debug.Print "tblBlahBlah", MyVar
30 Good code...
40 Debug.Print "tblBlahBlah", MyVar
50 Good code...
60 Debug.Print "tblBlahBlah", MyVar
70 Good code...
80 Debug.Print "tblBlahBlah", MyVar
90 Bad code...

The above illustrates the situation. I have the erroneous line of code
in Line #90. About 1/3 of the time, lines 20/40/60/80 result in some-
thing really showing up in the immediate window by the time the bad
code in Line #90 is trapped and the error msg displayed - and about
2/3 of the time it does not. It seems as if there's a RACE between VBA
running successive lines and the debug.print statement actually
writing to the immediate window.

time

[MLH]

Thx, Tom.

I'm glad to hear that. How does DoEvents come into play with that?
10 Time = "21:14:05"
20 Debug.Print Time
Based on your comment, I shouldn't worry about sticking a DoEvents
stmt between lines 10 and 20. That's a relief. I'm never really sure
of where I need to stick a DoEvents or not. Of course, it was designed
for some use.

It does NOT work like that.
VBA, and all other languages I know of, execute code in one procedure
("stack frame") sequentially, NOT in some multi-threaded way.
In your example, a Debug.Print line would execute BEFORE the next line
executes. Just think about the consequences if that were not the case.
x=4
x=5
Msgbox x 'Crap shoot if this displays 4 or 5.

-Tom.

Is it a common occurrence for A97 VBA to 'RACE' on past
a debug.print statement?

I have been trying to debug a problem (which turned out to
be an attempt to assign Null to a Date Type variable) and had
several debug.print statements...

10 Good code...
20 Debug.Print "tblBlahBlah", MyVar
30 Good code...
40 Debug.Print "tblBlahBlah", MyVar
50 Good code...
60 Debug.Print "tblBlahBlah", MyVar
70 Good code...
80 Debug.Print "tblBlahBlah", MyVar
90 Bad code...

The above illustrates the situation. I have the erroneous line of code
in Line #90. About 1/3 of the time, lines 20/40/60/80 result in some-
thing really showing up in the immediate window by the time the bad
code in Line #90 is trapped and the error msg displayed - and about
2/3 of the time it does not. It seems as if there's a RACE between VBA
running successive lines and the debug.print statement actually
writing to the immediate window.

time

[MLH]

How does one, then, know if you're lying?
Perhaps you could insert a brief comment
at the end of your post indicating whether
its a lie or not. Better still, you could ignore
the post. I'll leave it up to your good judgment.

[Tom van Stiphout]

On Mon, 28 Nov 2005 01:05:14 -0500, MLH <CR**@NorthState.net> wrote:

DoEvents makes code re-entrant:
private sub Button0_Click()
for i=1 to 100000
DoSomeThing
DoEvents
next
end sub

This would allow you to click the button multiple times, and multiple
stack frames will run the loop.
Still, this is far from unpredictable, and far from running things out
of order. Rather it is perfectly logical execution, and each
instruction occurs sequentially as it should.

-Tom.

Thx, Tom.

I'm glad to hear that. How does DoEvents come into play with that?
10 Time = "21:14:05"
20 Debug.Print Time
Based on your comment, I shouldn't worry about sticking a DoEvents
stmt between lines 10 and 20. That's a relief. I'm never really sure
of where I need to stick a DoEvents or not. Of course, it was designed
for some use.

It does NOT work like that.
VBA, and all other languages I know of, execute code in one procedure
("stack frame") sequentially, NOT in some multi-threaded way.
In your example, a Debug.Print line would execute BEFORE the next line
executes. Just think about the consequences if that were not the case.
x=4
x=5
Msgbox x 'Crap shoot if this displays 4 or 5.

-Tom.

Is it a common occurrence for A97 VBA to 'RACE' on past
a debug.print statement?

I have been trying to debug a problem (which turned out to
be an attempt to assign Null to a Date Type variable) and had
several debug.print statements...

10 Good code...
20 Debug.Print "tblBlahBlah", MyVar
30 Good code...
40 Debug.Print "tblBlahBlah", MyVar
50 Good code...
60 Debug.Print "tblBlahBlah", MyVar
70 Good code...
80 Debug.Print "tblBlahBlah", MyVar
90 Bad code...

The above illustrates the situation. I have the erroneous line of code
in Line #90. About 1/3 of the time, lines 20/40/60/80 result in some-
thing really showing up in the immediate window by the time the bad
code in Line #90 is trapped and the error msg displayed - and about
2/3 of the time it does not. It seems as if there's a RACE between VBA
running successive lines and the debug.print statement actually
writing to the immediate window.

time

[Lyle Fairfield]

MLH wrote:

I don't know. I got tired of screwing with it. The age-old fallback
for me has always been MsgBox. I give up the ability to select &
copy the output, but it never fails to show up.

One can copy the text output of a MsgBox with <Ctrl><C> while the
MsgBox is displayed.
One can copy the graphic output with <Alt><PrtScr>.

To tell if I am lying, try what I have suggested.

[MLH]

All I can say is good luck to anyone who believes CTRL-C will
copy the contents of a MsgBox to the clipboard. Shift-PrtScr has
always worked for me. I wouldn't know anything about ALT-PrtScr,
I have never used it.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxx

MLH wrote:

I don't know. I got tired of screwing with it. The age-old fallback
for me has always been MsgBox. I give up the ability to select &
copy the output, but it never fails to show up.

One can copy the text output of a MsgBox with <Ctrl><C> while the
MsgBox is displayed.
One can copy the graphic output with <Alt><PrtScr>.

To tell if I am lying, try what I have suggested.

[MLH]

Thx, Tom.
xxxxxxxxxxxxxxxxxxxxxxxx

DoEvents makes code re-entrant:
private sub Button0_Click()
for i=1 to 100000
DoSomeThing
DoEvents
next
end sub

This would allow you to click the button multiple times, and multiple
stack frames will run the loop.
Still, this is far from unpredictable, and far from running things out
of order. Rather it is perfectly logical execution, and each
instruction occurs sequentially as it should.

-Tom.

Thx, Tom.

I'm glad to hear that. How does DoEvents come into play with that?
10 Time = "21:14:05"
20 Debug.Print Time
Based on your comment, I shouldn't worry about sticking a DoEvents
stmt between lines 10 and 20. That's a relief. I'm never really sure
of where I need to stick a DoEvents or not. Of course, it was designed
for some use.

It does NOT work like that.
VBA, and all other languages I know of, execute code in one procedure
("stack frame") sequentially, NOT in some multi-threaded way.
In your example, a Debug.Print line would execute BEFORE the next line
executes. Just think about the consequences if that were not the case.
x=4
x=5
Msgbox x 'Crap shoot if this displays 4 or 5.

-Tom.
Is it a common occurrence for A97 VBA to 'RACE' on past
a debug.print statement?

I have been trying to debug a problem (which turned out to
be an attempt to assign Null to a Date Type variable) and had
several debug.print statements...

10 Good code...
20 Debug.Print "tblBlahBlah", MyVar
30 Good code...
40 Debug.Print "tblBlahBlah", MyVar
50 Good code...
60 Debug.Print "tblBlahBlah", MyVar
70 Good code...
80 Debug.Print "tblBlahBlah", MyVar
90 Bad code...

The above illustrates the situation. I have the erroneous line of code
in Line #90. About 1/3 of the time, lines 20/40/60/80 result in some-
thing really showing up in the immediate window by the time the bad
code in Line #90 is trapped and the error msg displayed - and about
2/3 of the time it does not. It seems as if there's a RACE between VBA
running successive lines and the debug.print statement actually
writing to the immediate window.

time

[Lyle Fairfield]

MLH wrote:

All I can say is good luck to anyone who believes CTRL-C will
copy the contents of a MsgBox to the clipboard.

You're wishing good luck to everyone? How kind of you!

[Tim Marshall]

MLH wrote:

All I can say is good luck to anyone who believes CTRL-C will
copy the contents of a MsgBox to the clipboard.

I tried this - it works nicely in A2003, but does not work in my
installation of A97, which is of concern to you. Still thanks to Lyle
for a useful hint I hadn't encountered before.

--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[David W. Fenton]

Tim Marshall <TI****@PurplePandaChasers.Moertherium> wrote in
news:dm**********@coranto.ucs.mun.ca:

MLH wrote:

All I can say is good luck to anyone who believes CTRL-C will
copy the contents of a MsgBox to the clipboard.

I tried this - it works nicely in A2003, but does not work in my
installation of A97, which is of concern to you. Still thanks to
Lyle for a useful hint I hadn't encountered before.

But you could use Terry Kreft's clipboard API functions to copy the
message to the clipboard before the MsgBox loads, and then you'd
have the same data as you'd get in later versions of Access:

http://www.mvps.org/access/api/api0049.htm

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

MLH <CR**@NorthState.net> wrote in
news:c9********************************@4ax.com:

All I can say is good luck to anyone who believes CTRL-C will
copy the contents of a MsgBox to the clipboard. Shift-PrtScr has
always worked for me. I wouldn't know anything about ALT-PrtScr,
I have never used it.

Lyle very often neglects to consider that others aren't using the
latest version of Access.

He is correct that in later versions of Access, Ctrl-C works.

He just doesn't pay close enough attention to know that you're
working in A97.

As I said in another post, you could replicate this functionality by
copying the message text to the clipboard before the call to the
MsgBox function using Terry Kreft's clipboard API code:

http://www.mvps.org/access/api/api0049.htm

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Lyle Fairfield]

Is it the Windows version or the Office Version?
If your Ac2003 and your AC97 are on the same machine then we can
conclude it's the Office version?

[Sky]

"Lyle Fairfield" <ly***********@aim.com> wrote in message
news:11**********************@g47g2000cwa.googlegr oups.com...

Is it the Windows version or the Office Version?

In Access 2000,

Ctrl-C works to copy this:
MsgBox "Hello"

Ctrl-C fails to copy this:
Eval("MsgBox(""Hello With Eval"")")

The latter can be used to permit bold face with the "@" symbol, just
like
Access 97.

- Steve

[Tim Marshall]

David W. Fenton wrote:

But you could use Terry Kreft's clipboard API functions to copy the
message to the clipboard before the MsgBox loads, and then you'd
have the same data as you'd get in later versions of Access:

http://www.mvps.org/access/api/api0049.htm

True. I use Terry's clipboard APIs a lot in my apps. Still, I think it
far easier for MLH to just do the very basics I suggested in a post he
probably hasn't seen, a suggestion similar to Thelma Lubkin's. Perhaps
I've yelled at him too many times, myself. Though, maybe if we all did
it instead of being so touchy-feely-let's-not-hurt-his-feelings he might
learn some goddamn thing and RTFM first instead of constant posting over
stuff that one should be able to find in the great A97 help file. Mind
you, this particular thread is probably a legitimate question for a
newbie...
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[Tim Marshall]

Lyle Fairfield wrote:

Is it the Windows version or the Office Version?
If your Ac2003 and your AC97 are on the same machine then we can
conclude it's the Office version?

Both from the respective Office Pro packages. What's the Windows
version? Is that just Access by itself? Is there a distinction btween
the two?

--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[Lyle Fairfield]

Access like almost every application does nothing itself; it calls OS
functions; they do the work. It's conceivable (at least to me) that the
difference noted in <Ctrl><C> and MsgBox could be due to the Windows
version (say Windows 98 as opposed to Windows XP) and not the Office
version.

[Terry Kreft]

Sorry Lyle it's not.

Windows Server 2003
Office 2003 - msgbox - Ctrl-C you can paste the text into notepad
Office 97 - msgbox - Ctrl-C you can't paste the text into notepad

--
Terry Kreft

"Lyle Fairfield" <ly***********@aim.com> wrote in message
news:11*********************@g49g2000cwa.googlegro ups.com...

Access like almost every application does nothing itself; it calls OS
functions; they do the work. It's conceivable (at least to me) that the
difference noted in <Ctrl><C> and MsgBox could be due to the Windows
version (say Windows 98 as opposed to Windows XP) and not the Office
version.

[Trevor Best]

Lyle Fairfield wrote:

Access like almost every application does nothing itself; it calls OS
functions; they do the work. It's conceivable (at least to me) that the
difference noted in <Ctrl><C> and MsgBox could be due to the Windows
version (say Windows 98 as opposed to Windows XP) and not the Office
version.

As Sky correctly pointed out, using Eval(Msgbox) you can't use Ctrl+C
and supports A97's @ formatting, I've not got A97 to test but from that
I would deduce that it's down to the Access version if not both.

[MLH]

It does sound pretty cool.
xxxxxxxxxxxxxxxxxxxxxxxxxxx

On Mon, 28 Nov 2005 11:47:39 -0330, Tim Marshall
<TI****@PurplePandaChasers.Moertherium> wrote:

MLH wrote:

All I can say is good luck to anyone who believes CTRL-C will
copy the contents of a MsgBox to the clipboard.

I tried this - it works nicely in A2003, but does not work in my
installation of A97, which is of concern to you. Still thanks to Lyle
for a useful hint I hadn't encountered before.