Problem with command buttons on switchboards and forms.

[Chris Bolus]

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?

[Tom Wickerath]

Re: Problem with command buttons on switchboards and forms.

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 'CommandButtonN ame_Click' already exists. Please try a new command
button name."

where CommandButtonNa me 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 cmdOpenEmployee sForm. 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 cmdOpenEmployee sForm_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: cmdOpenEmployee sForm (or whatever name you
want to use for this example). In Access 2000 and earlier, you will now find two
cmdOpenEmployee sForm_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.aspx?scid=kb;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.microso ft.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.aspx?scid=kb;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....Teachin g is NOT an easy job! I did it for three years.

Tom Wickerath
_______________ _______________ _______

"Chris Bolus" <google@b0lus.c om> wrote in message
news:8dbd488.03 11090917.6623a2 15@posting.goog le.com...
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?

[Chris Bolus]

Re: Problem with command buttons on switchboards and forms.

"Tom Wickerath" <AOS168RemoveTh isSpamBlock@com cast.net> wrote in message news:<6dKdnWHRk qpKADOiRVn-iw@comcast.com> ...[color=blue]
> Hi Chris,
>
> The second problem is an easy one! It sounds to me like you are using Access 2000[/color]
You're right.[color=blue]
>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.[/color]
That's really helpful, thanks.
[color=blue]
> 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.microso ft.com[/color]
Yes, I know about the knowledgebase, just never though to look in this
case. I think however it would prove too technical for many of my
students and confuse them even more.
[color=blue]
> 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.[/color]

That does sound likely. I'll give it a try. RM Networks can be tricky
with things like this.[color=blue]
>
> Good Luck....Teachin g is NOT an easy job! I did it for three years.[/color]
It's even harder in an inner city (by definition, not by location)
school which is in special measures - that's where the inspectors have
said it's not up to scratch and we have to work harder to improve
things else they close us down.

Thanks so much for your help; despite 15 years teaching I'm still a
bit of a beginner with Access.


--
Chris

https://www.b0lus.com