hollering
asked on
Format() and Command() causing compile errors in Access 97
I have many databases that use the format() and command() functions for various common purposes...for instance format for creating error/activity logs and I use command along with the /cmd switch to send my database into developer mode.
I've been using these for some time now without any problems, but recently one computer has given me fits. Everytime I try to run one of my apps on her computer I get a lot of compile errors. She had a full version of Access 97, so I tried running it with Access Runtime. Same problems. Any ideas?
Urgency is kinda high on this one. I would like to have this fixed before my user returns from her vacation....thus the 500 points.
I've been using these for some time now without any problems, but recently one computer has given me fits. Everytime I try to run one of my apps on her computer I get a lot of compile errors. She had a full version of Access 97, so I tried running it with Access Runtime. Same problems. Any ideas?
Urgency is kinda high on this one. I would like to have this fixed before my user returns from her vacation....thus the 500 points.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Jim Horn
Define 'command()' function.
Jimhorn, VBA.Interaction.Command() is the function used to return the command line arguments used to open the application session.
This., along with VBA.Strings.Format(...), should be available from the Visual Basic For Applications library, which is a a non-dereferencable reference. However, as phileoca mentions, you should check to see if any other references may be missing, hollering. These often cause the compiler to be "tripped up" when trying to determine the scope of library functions.
You could also try using explicit scope referencing instead of implicit to avoid this problem. That is, VBA.Interaction.Command() rather than just Command().
Another possibility might simply be a version issue on the problem machine. Ensure that it has the latest installation of the VBA library files. These are usually located in subdirectories of C:\Program Files\Microsoft Shared\VBA\.
This., along with VBA.Strings.Format(...), should be available from the Visual Basic For Applications library, which is a a non-dereferencable reference. However, as phileoca mentions, you should check to see if any other references may be missing, hollering. These often cause the compiler to be "tripped up" when trying to determine the scope of library functions.
You could also try using explicit scope referencing instead of implicit to avoid this problem. That is, VBA.Interaction.Command() rather than just Command().
Another possibility might simply be a version issue on the problem machine. Ensure that it has the latest installation of the VBA library files. These are usually located in subdirectories of C:\Program Files\Microsoft Shared\VBA\.
Learn something new every day. So is it possible to shell open an Access app, with command-line arguments, and then in Access' startup code use VBA.Interaction.Command() to read the command-line arguments?
(I had an EE question on that a week ago...)
(I had an EE question on that a week ago...)
yes, jim that is precisely what thew Command() function does. It returns, as its value, whatever was on the command line, AFTER the identifier of the executable
Access.Exe CommandString
will result in CommandString to be returned as the value of Command() { or Command$} in the Open Event of the StartUp form of the APP. look up Command$ in the Access online Help system.
AW
Access.Exe CommandString
will result in CommandString to be returned as the value of Command() { or Command$} in the Open Event of the StartUp form of the APP. look up Command$ in the Access online Help system.
AW
Thanks for the explanation. I will remember that one...
ASKER
Yeah this is extremely handy. Using command() I've been successfully able to lock up my apps good and tight, with no shift bypass key and all custom menus. Then when I want to work in the database, I have a database maintenance interface that uses shell to open the databases with "/cmd devmode" attached to the end...which tells my opening form to cancel and reenable everything. Then it shuts down the database and reopens it with "/cmd postdevmode" which restores all the lock-down settings (which don't get applied until the next time the database is opened). So it has similar effects to the shift bypass key...only my users don't know about it. They have a habit of trying to go behind the scenes to manipulate data directly rather than telling me that they need a certain functionality built in.
That said, I checked references. There is a reference missing to mscomctl.ocx..."Microsoft Windows Common Controls 6"...however, I was unable to find this file on the client computer, who is running Win 98 (I develop in Win 2k). Is it safe to distribute the ocx with the database? It's just a plug-in right? Please advise.
That said, I checked references. There is a reference missing to mscomctl.ocx..."Microsoft Windows Common Controls 6"...however, I was unable to find this file on the client computer, who is running Win 98 (I develop in Win 2k). Is it safe to distribute the ocx with the database? It's just a plug-in right? Please advise.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
We are slowly migrating users to XP as their machines are upgraded...at a rate of about one every two weeks. For now it is a necessary evil to have 3 different operating systems among the user base.
In reply to your suggestion. I dereferenced Common Controls and it compiled fine on my machine. I'm heading over to see if the client's computer does better now that the unnecessary reference has been removed.
In reply to your suggestion. I dereferenced Common Controls and it compiled fine on my machine. I'm heading over to see if the client's computer does better now that the unnecessary reference has been removed.
ASKER
Well...that worked...sort of. The user I was having trouble with has both Access 97 and the Access 97 runtime installed. The runtime worked once I removed the reference to mscomctl. The full version gave me an error when it started up saying that it could not find the VBA dll. So everything should be fine once I reinstall Access. Worst case scenario...the user gets stuck using runtime, which will work fine anyway.
I'm a little bent over the point scenario. Arthur, your post was a direct answer to my question, but it came after phileoca made the suggestion to check references. I'm going to split up the points. Thanks to all of you for helping!
I'm a little bent over the point scenario. Arthur, your post was a direct answer to my question, but it came after phileoca made the suggestion to check references. I'm going to split up the points. Thanks to all of you for helping!