Hi Chris,
The second problem is an easy one! It sounds to me like you are using Access 2000 or
earlier, because Access 2002 has some built-in logic to avoid this type of problem. When
using the command button wizard, Access 2002 will inform the user:
"An event procedure 'CommandButtonName_Click' already exists. Please try a new command
button name."
where CommandButtonName is the name that the user attempted to enter in the final screen
of the wizard.
The cause of this problem is typically deleting a command button on a form without first
deleting VBA (Visual Basic for Applications) code that is associated with this button. I
call this leaving "spider webs" (unused code procedures) behind in your code. Say you
create a command button, using the wizard, and you name it cmdOpenEmployeesForm. While
VBA code may be beyond the scope of your course, you should be award that the wizard is
creating VBA code for you behind the scenes. Now, if you delete this command button, you
will still have the associated click event procedure named cmdOpenEmployeesForm_Click()
hanging around in your code. Now the student decides that they really needed this command
button, so they repeat the process of using the wizard to create a second command button,
and they name it exactly the same as before: cmdOpenEmployeesForm (or whatever name you
want to use for this example). In Access 2000 and earlier, you will now find two
cmdOpenEmployeesForm_Click() subroutines in the code. Access complains that it doesn't
know which one you really want to run with the ambiguous name error. Here is Microsoft's
explanation of the same error:
http://support.microsoft.com/default...b;en-us;817411
I used to teach Access P/T at Bellevue Community College (Bellevue, WA. USA). I would
always advise my students to delete any code associated with a control, before deleting
the control, to avoid the spider webs. To do this, view the properties for the command
button that you are about to delete. Click on the Event tab. If you see an "Event
Procedure" listed, for any of the possible events, then click on the associated build
button (three dots) to find the subroutine or function. Select the procedure and delete
it. By the way, FMS's Total Access Analyzer software does a great job of detecting unused
procedures like this.
You might also want to teach your students how to find information in the Microsoft
Knowledge Base. I always had my students memorize one URL: support.microsoft.com if they
were going to work with any Microsoft software. Note: there is no www in this URL. If
you search the KB, using "ambiguous name error" (without the quotes) as the search term,
you should be able to find the KB article I show above.
On one occasion, I believe I experienced the first problem that you reported, although its
been so long now that I'm not sure the error message was exactly the same. In any case,
it was definitely an error associated with attempting to use the command button wizard.
If you search the KB for "command button wizard" (again, without the quotes) one of the
articles you will find is titled:
ACC2000: Wizard Names and Their Locations
http://support.microsoft.com/default...b;en-us;208307
Under "Builders", we see that the file used is named acwzmain.mde. In my case, I was able
to fix the problem on this PC by taking a copy of this file from my workstation and
replacing the copy on the student's workstation. An .MDE file is an Access database in
itself. It had apparently become corrupted on the student's workstation.
Good Luck....Teaching is NOT an easy job! I did it for three years.
Tom Wickerath
_____________________________________
"Chris Bolus" <go****@b0lus.com> wrote in message
news:8d*************************@posting.google.co m...
I'm a teacher using MS Access on an RMConnect 2.4 network. On some
workstations both I and my students sometimes get an error message
when attempting to insert a command button on a form which reads
"Invalid use of null". The remainder of the options in the Command Button
Wizard are then unavailable and
the button wil not work.
The only solution is to log on to a different workstation.
Any ideas?
My second problem is more user-specific, and has so far only affected
two students. Again this is associated with command buttons, either in
forms or switchboards, such that when the button is clicked an error
message comes up to the effect of "Ambiguous name
detected:books_click" (actual name varies). This usually loads the
Visual Basic debugger, which is outside the scope of what my students
are doing. I don't have enogh knowledge of Vbasic to sort this anyway.
Again, any ideas?
