How Do You Debug These Problems?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have a DblClick event procedure that has an OpenForm method call:

DoCmd.OpenForm "fmTickets", acNormal, , "RemTkt = " & ticketID,
acFormEdit, acWindowNormal

If all goes well the Cancel argument of the Event Procedure is set to False.
If not, control transfers to an error handling block and sets Cancel to True.
There is an Exit Sub before the error handler, so execution isn't dropping
through. The debugger shows control skipping into the error handler.

As soon as I hit this statement, an error/exception is raised which causes
an "OpenForm cancelled" message (Access Error 2501) to be issued. I have read
all of the online documentation I can find and can come up with no reason for
this happening. (Although that may be the result of tunnel vision by this
point in time.)

My question is not so much "Why is this happening?" as "How does one debug
this?" Single stepping through the code tells me nothing; as soon as the
statement is executed, control transfers to my error handler and issues the
message. (without the error handler, nothing at all appears! The form never
shows up, but there is also no popup!) But I have no way of getting 'inside'
the execution to find out why the cancel occurs. I'm sure this is not the
only example of where someplace inside a method call an exception is raised
and nothing obvious is revealed to the programmer. How do the experts deal
with these?

Trolling for knowledge. TIA.
 
Pretty much as you have, look through the documentation, pull our hair out
and ask someone else.

I don't class myself as an expert by a distance, but certainly I feel
comfortable with Access; yet the people whom I have considered experts have
often come to me to talk through a problem.
Sure, I might not have the answer, but getting the question out and
actually talking it through can sometimes trigger the answer in your own
mind. This was usually the case, and my boss would sit with me for 5
minutes before getting up and legging it back to his desk before he forgot
what he had just thought about; which was often very amusing to watch.

In this case I would first check:

1. There really is a form called "frmTickets"
2. You really are able to edit records with this form
3. There is a field called "RemTkt" in the forms underlying data source
4. That ticketID is a valid number to be used on the form

Other than that, I'm afraid I don't know what to suggest. Maybe one of the
true experts may be able to offer something more?

Cheers

John Webb
 
Chaim said:
I have a DblClick event procedure that has an OpenForm method call:

DoCmd.OpenForm "fmTickets", acNormal, , "RemTkt = " & ticketID,
acFormEdit, acWindowNormal

If all goes well the Cancel argument of the Event Procedure is set to
False. If not, control transfers to an error handling block and sets
Cancel to True. There is an Exit Sub before the error handler, so
execution isn't dropping through. The debugger shows control skipping
into the error handler.

As soon as I hit this statement, an error/exception is raised which
causes an "OpenForm cancelled" message (Access Error 2501) to be
issued. I have read all of the online documentation I can find and
can come up with no reason for this happening. (Although that may be
the result of tunnel vision by this point in time.)

My question is not so much "Why is this happening?" as "How does one
debug this?" Single stepping through the code tells me nothing; as
soon as the statement is executed, control transfers to my error
handler and issues the message. (without the error handler, nothing
at all appears! The form never shows up, but there is also no popup!)
But I have no way of getting 'inside' the execution to find out why
the cancel occurs. I'm sure this is not the only example of where
someplace inside a method call an exception is raised and nothing
obvious is revealed to the programmer. How do the experts deal with
these?

Trolling for knowledge. TIA.

Probably you where-condition is invalid, causing the OpenForm action to
be cancelled. For example, if the field RemTkt is a text field and
ticketID is a number, that will happen. If that's the case, you must
build the where-condition so that the value of ticketID is enclosed in
quotes. It might look like this:

DoCmd.OpenForm _
"fmTickets", acNormal, , _
"RemTkt = '" & ticketID & "'", _
acFormEdit, acWindowNormal

As for how one learns such things, the best answer I can give is
"experience -- and reading the newsgroups." That'll sound a lot wiser
if I turn out to be right about your problem, of course. <g>
 
Dirk,

Thank you much. You couldn't have hit the nail any more directly on the
head. I had (frantically- bad state for a software guy to be in ;->) checked
all of the form properties but because of the nature of the RemTkt field
(which should probably be numeric) I never bothered to check that! In fact,
so convinced was I that it was numeric, that I had a line "remTicket =
val(Me!txtRemTkt)" to convert it to a numeric.

As I said in my original post, "the result of tunnel vision".

Once again, thank you very much.
 
Back
Top