Automated Access launch causing Access window to fail to hide

[Guest]

I have been using "fSetAccessWindow (SW_HIDDEN)" in the open event of my
main switchboard to hide the grey Access screen from being visible behind
forms, reports, etc in this db. But when I started using a .vbs script file
to launch the db, the Access window stopped being hidden. (The reason I use
the script for launching is that it temporarily sets the db's security level
to 1 which stops the macro security warning from coming up.) Apparently MS
knows about this happening and released a technique to rectify the situation,
but I don't understand their instructions. It looks like they expect one to
have more understanding than I have. Could someone help me get this
impliemented? Here is the article:
http://support.microsoft.com/kb/167659/en-us

 

[Robin]

I have been using "fSetAccessWindow (SW_HIDDEN)" in the open event of my

main switchboard to hide the grey Access screen from being visible behind
forms, reports, etc in this db. But when I started using a .vbs script
file
to launch the db, the Access window stopped being hidden. (The reason I
use
the script for launching is that it temporarily sets the db's security
level
to 1 which stops the macro security warning from coming up.) Apparently MS
knows about this happening and released a technique to rectify the
situation,
but I don't understand their instructions. It looks like they expect one
to
have more understanding than I have. Could someone help me get this
impliemented? Here is the article:
http://support.microsoft.com/kb/167659/en-us

I'm not sure the kb article you refer to has anything to do with the issue
you describe. The kb article is about hiding a complete instance of Access
during Automation - not just hiding the 'grey' application area.

 

[Guest]

What you're saying may be true, but I'd like to test it on a test db just to
see.
Could you help me implement the fix for testing?

 

[Robin]

What you're saying may be true, but I'd like to test it on a test db just

to
see.
Could you help me implement the fix for testing?

I'm sure it's a totally different problem. The kb fix will hide the entire
db to the point that you will only see it running by looking in Task
Manager.

 

[Guest]

You're probably right, I'm sure, but could you help me test it? Don't take
it the wrong way (since obviously I don't know you or your skills) but no one
seems to be able to help wiht this and this is all I've found so I'd like to
just test it, just to eliminate it.

 

['69 Camaro]

Hi.

no one
seems to be able to help wiht this and this is all I've found

It's generally a bad idea to blindly copy and paste code that you've found
that you couldn't have written yourself with a little help, because you
won't know if a disaster is about to befall you when you execute the code,
and you won't know where to start when you need to fix the problems that
arise.

This is going to sound harsh, because it is. You went on an Internet Easter
Egg hunt and found some code to put in your basket, including
fSetAccessWindow( ), the VB Script to set Automation Security, and now the
KB article. You don't know what the code in the KB article does or how to
implement it for your purposes, but you expect someone to take the time to
test it for you. Experienced programmers will be reluctant to do so because
they already know why it won't work, but if you're going to become an
experienced programmer, then you need to test it yourself so that you can
learn. And we do want you to learn, so don't be surprised if no one steps
up to the plate to show you code that fails to do what you want it to do as
"proof" that the KB article code doesn't work for your situation.

Look at the code. It contains a Windows API call. VB Script doesn't
support Windows API calls, so you can't use this code in your script to open
and hide the Access instance, then set Automation Security before opening
the database.

Again, look at the code. It hides the instance of Access (startup form and
all if you added the OpenCurrentDatabase method in the code to open your
database file) until the user selects the "OK" button on the message box,
then the entire application becomes visible. This isn't what you want. You
want to see the forms, reports, et cetera, sans the Access title bar, menus,
status bar, et cetera.

So the question is, which is more important, hiding the Access application
background or setting Macro Security to Medium or higher? If you're like
most people, you don't need Macro Security set permanently to a level higher
than low. Most people who are setting it to Medium or High are doing so
because they think their computers are going to be secure, only to find out
(should they ever check) that these Access Macro Security levels don't meet
their definitions of secure.

What definition of secure do you hope Access Macro Security is going to
meet? Are you hoping it detects viruses in your database file? It can't.
Use your antivirus software to detect whether or not a virus has been
embedded in the file. What else do you hope Access Macro Security is
protecting you from?

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact
info.

 

[Guest]

I think you're right about the security level. The best solution for me is
to set it to Low.
Thanks everyone.

 

[Robin]

I think you're right about the security level. The best solution for me is

to set it to Low.
Thanks everyone.

I would also question the use of fSetAccessWindow( ). From experience this
disables many right click context menus, and Controls/images on a form
flicker unacceptably when navigating between records. I suspect this is
using a crazy amount of processor overhead to achieve almost nothing.