Debugging a Form

[Guest]

I converted an Access 97 mdb to Access 2003 and am getting undesirable
behavior when debugging. I have tried it on three different computers with
same result. I have a form with a single command button. and two procedures
as shown below:

Public Function TestProcedure()
Dim s As String
Dim dt As Date
s = "12/31/2005"
dt = s & "aaaa"
End Function

Private Sub Command0_Click()
Call TestProcedure
End Sub

IN the properties dialog for the button control, I can set the On Click
property to either (1) [Event Procedure] or (2) =TestProcedure()

The first method setting works fine. When I click the button I get a Dialog
that says Run-time error, Type mismatch with buttons for End, Debug, etc.
This is the behavior that I want.

When I use the second method, I do not get this dialog, instead I get a
Message box that says: "The expression ON Click you entered as the event
property setting produced the following error: Type mismatch." The statement
is correct but instead of giving me an option to debug, I only have two
buttons that have titles of "Show Help>>' and "OK". There is no debug button
and no way for me to go to find the bad line of code. In Access 97, you got
the same dialog regardless of the way you defined the On click event. Can
someone offer me a solution to this problem? I have all the latest updates.

 

[Van T. Dinh]

Try s = #12/31/2005#

Usually Access converts from the text you supplied to date value (due to the
declaration). However, it is better if you use the correct data type when
assigning explicit values.

I tend not to use " = Function()" syntax because in proper programming, a
function should return values without any process action. In the above
syntax , the function value is ignored and the process action is actually
required.

--
HTH
Van T. Dinh
MVP (Access)

I converted an Access 97 mdb to Access 2003 and am getting undesirable
behavior when debugging. I have tried it on three different computers with
same result. I have a form with a single command button. and two procedures
as shown below:

Public Function TestProcedure()
Dim s As String
Dim dt As Date
s = "12/31/2005"
dt = s & "aaaa"
End Function

Private Sub Command0_Click()
Call TestProcedure
End Sub

IN the properties dialog for the button control, I can set the On Click
property to either (1) [Event Procedure] or (2) =TestProcedure()

The first method setting works fine. When I click the button I get a Dialog
that says Run-time error, Type mismatch with buttons for End, Debug, etc.
This is the behavior that I want.

When I use the second method, I do not get this dialog, instead I get a
Message box that says: "The expression ON Click you entered as the event
property setting produced the following error: Type mismatch." The statement
is correct but instead of giving me an option to debug, I only have two
buttons that have titles of "Show Help>>' and "OK". There is no debug button
and no way for me to go to find the bad line of code. In Access 97, you got
the same dialog regardless of the way you defined the On click event. Can
someone offer me a solution to this problem? I have all the latest

updates.

 

[Guest]

This response does not come close to answering the question. I have a
deliberate syntax error in my code to force Access to display an error
message. The error could have been anything.

By using the =TestProcedure(), Access 2003 responds with one message, by
using [Event Procedure], the Access 2003 response is different even though
the executed code is identical. One response lets me easily debug code, the
other response does not.

I am interested in the more general question of debugging code when it
contains events that are defined with =TestProcedure() type of statement. It
worked great in Access 97.

 

[Rick Brandt]

This response does not come close to answering the question. I have a
deliberate syntax error in my code to force Access to display an error
message. The error could have been anything.

By using the =TestProcedure(), Access 2003 responds with one message,
by using [Event Procedure], the Access 2003 response is different
even though the executed code is identical. One response lets me
easily debug code, the other response does not.

I am interested in the more general question of debugging code when it
contains events that are defined with =TestProcedure() type of
statement. It worked great in Access 97.

Do you have the Error Trapping options set the same in the advanced Options for
both versions?

 

[Allan Murphy]

Putting your function as a module you will get the dialog box to debug the
code

--
Allan Murphy
Email: (e-mail address removed)

I converted an Access 97 mdb to Access 2003 and am getting undesirable
behavior when debugging. I have tried it on three different computers with
same result. I have a form with a single command button. and two procedures
as shown below:

Public Function TestProcedure()
Dim s As String
Dim dt As Date
s = "12/31/2005"
dt = s & "aaaa"
End Function

Private Sub Command0_Click()
Call TestProcedure
End Sub

IN the properties dialog for the button control, I can set the On Click
property to either (1) [Event Procedure] or (2) =TestProcedure()

The first method setting works fine. When I click the button I get a Dialog
that says Run-time error, Type mismatch with buttons for End, Debug, etc.
This is the behavior that I want.

When I use the second method, I do not get this dialog, instead I get a
Message box that says: "The expression ON Click you entered as the event
property setting produced the following error: Type mismatch." The statement
is correct but instead of giving me an option to debug, I only have two
buttons that have titles of "Show Help>>' and "OK". There is no debug button
and no way for me to go to find the bad line of code. In Access 97, you got
the same dialog regardless of the way you defined the On click event. Can
someone offer me a solution to this problem? I have all the latest

updates.

 

[Albert D.Kallal]

Hum, interesting, I never noticed the difference, but the behaviors you
describe seems to be normal now.

About the only suggestion I can give is to put error handling in your code,
and thus the error will be trapped, and in both cases you will thus get the
same error message.

I suspect this change is the result of the expression builder being part of
ms-access, but the code, and debugging part has been moved out to VB (in
fact, we now share the same IDE and compiler as VB6).

I doubt a lecture about error handling being a good idea here is
moot.........and I do think what you point out is a bit of a step backwards
for the new version.

However, with my use of error handling, I have never noticed the change
until you pointed it out. Yours is the first post on this issue I can
remember.

We had 3 verisons of office since 97, and a 4th one is on the tarmac being
built as we speak. So, while this issue is a a step backwards, it is not a
large one.

 

[Guest]

Thanks to all for your help. Here is what I learned: Allan Murphy is
correct. Putting the function in a module did solve the problem.
Unfortunately, this does not solve my problem since I am dealing with legacy
software rather than new software. Moving these functions to a module is not
reasonable.

ADK, confirms my findings and provides reasonable commentary.

For my legacy software, error trapping does handle situations regarding the
end-user. If a situation occurs where I want to have the Debug feature
available, I will revise the code by replacing =TestProcedure() with [Event
Procedure] and make the appropriate change to the code. I will do this on an
as-needed basis.

In new software, I will probably avoid using =TestProcedure(). Why invite
problems.