Invalid use of null

  • Thread starter Thread starter Bill
  • Start date Start date
B

Bill

I have a needle in the haystack problem that so far I've
been unable to track down.


Environment: Win XP or 2K running Access XP Runtime

Problem: When running an MDE version of our application
the user logs into the program and is presented with the
main screen. At this point they can use various shortcuts
(ie. F2, F3, etc)

The first time they use the shortcut key the program will
work correctly, after that pressing the shortcut key (or
any for that matter) results in an "Invalid Use of Null"
error.

Now here's where it gets interesting. The user can close
the app and reopen it and use the shortcut key again once
then gets the error after that.

Also, without closing the app, if you change screen
resolution you are able to use the function key once, then
the error returns.

Any ideas??
 
Error 94 means you have attempted to assign the value Null to something
which cannot be Null.

In VBA code, only the Variant data type can be null, so this code will
generate an error if Text1 is blank:
Dim A as Integer
A = [Text1]

If you have a text box with a Default Value (so it has a value the first
time), and code clears the box, then the next time the code above will
result in error 94.

More information:
Common errors with Null
at:
http://allenbrowne.com/casu-12.html
 
| I have a needle in the haystack problem that so far I've
| been unable to track down.
|
|
| Environment: Win XP or 2K running Access XP Runtime
|
| Problem: When running an MDE version of our application
| the user logs into the program and is presented with the
| main screen. At this point they can use various shortcuts
| (ie. F2, F3, etc)
|
| The first time they use the shortcut key the program will
| work correctly, after that pressing the shortcut key (or
| any for that matter) results in an "Invalid Use of Null"
| error.
|
| Now here's where it gets interesting. The user can close
| the app and reopen it and use the shortcut key again once
| then gets the error after that.
|
| Also, without closing the app, if you change screen
| resolution you are able to use the function key once, then
| the error returns.
|
| Any ideas??
-------------
Checkout this article:

ACC2000: Errors Caused by Strong Typing in Microsoft Access 2000
http://support.microsoft.com/?=202352

Hope this helps,
 
-----Original Message-----
I have a needle in the haystack problem that so far I've
been unable to track down.


Environment: Win XP or 2K running Access XP Runtime

Problem: When running an MDE version of our application
the user logs into the program and is presented with the
main screen. At this point they can use various shortcuts
(ie. F2, F3, etc)

The first time they use the shortcut key the program will
work correctly, after that pressing the shortcut key (or
any for that matter) results in an "Invalid Use of Null"
error.

Now here's where it gets interesting. The user can close
the app and reopen it and use the shortcut key again once
then gets the error after that.

Also, without closing the app, if you change screen
resolution you are able to use the function key once, then
the error returns.

Any ideas??
.

After some further research I was able to get around this
problem by changing CBool(IsClose) to IsClose in the
rowsource of the combobox. For whatever reason, on some
systems the CBool function appears to stop working or
works differently. The rowsource also contained a call to
a function in the code, but uncertain if this has anything
to do with the problem. Still not sure why the
functionality of the CBool function stops working though.

Thanks for the input :)
 
I am assuming that you have defined F2, F3 in a macro assigning access keys
to perform certain actions when a user press the appropriate Function key?
If yes, is it possible that those keys are interrupting or also executing
built-in Functions of another program?
Example F2 and F4 reside in the 'code editor' window of Access. These
function keys perform the following actions: Open the Object Browser (f2)
and the Properties Window(f4). These are probably conflicting with each
other.
 
Back
Top