K
koolaidkidd1
I would like to make my top form (like a switchboard), into an executible
program so I don't have to open Access to get to it. How do I do it please.
program so I don't have to open Access to get to it. How do I do it please.
koolaidkidd1 said:I would like to make my top form (like a switchboard), into an
executible program so I don't have to open Access to get to it. How
do I do it please.
ManningFan said:There was a guy who rented a helicopter , and the pilot ends up getting
lost.
He flies past a building and sees someone in a window. So he holds up
a sign that says, "Where am I?"
The guy in the building writes, "In a helicopter".
So the pilot flys away, takes a left and a right and lands safely at
the airport.
The person who rented a helicopter is amazed. "How did you know how to
get here?", he says.
"Well, " came the reply. "When I got a technically correct but
completely useless answer from that guy, I knew I had to be at the
Microsoft headquarters".
ManningFan said:Well, if you develop code in VB and run it OUTSIDE of VB, it's a
stand-alone. It doesn't require the application used to develop it.
An Access database created in Developer version DOES NOT REQUIRE Access
to be present on the machine to run it. Thus, it is a stand-alone.
Pointing out that the runtime version of Access is necessary is akin to
pointing out that many EXEs write to your registry and need those
registry keys in order to run. Does that mean they're not stand-alone
apps if they require registry keys? Access Developer installs Access
Runtime, and a program like Quicken installs DLLS and reg keys. Those
extras are a given, there's no need to define them outside the scope of
the app.
Peyton Manning
Microsoft/NFL MVP
Have it your way, but there's no such thing as "an Access database created
in Developer version".
The Developer edition has always included Office Professional plus the
Access Developer Extensions (except, I believe, in Office 2000, when it was
possible to purchase the ADE separately, and now Visual Studio Tools for
Office only includes ADE). In all cases, Access Developer Extensions will
not install unless Access has been installed.
You create the application using Access. Once you've created the
application, you use ADE to package the application together with the
run-time version of Access. As stated before, packaging the application
makes no changes whatsoever to the application.
The run-time version is the exact same executable (msaccess.exe) as the
"regular" version of Access. The only difference is that design features
have been turned off in the run-time version through literally hundreds of
registry settings. In other words, Access IS present when the run-time is
installed. If it weren't, the application wouldn't work.
This is similar to VB, by the way. An executable compiled in Visual Basic
will not work unless the VB runtime files are present on the client machine.
Older versions of Windows didn't automatically include the VB runtime files,
like WIndows XP does (and Vista will): it was necessary to create an install
package to ensure that the VB runtime files were installed before the VB
executable could be used (The similarity ends there, though: the VB runtime
isn't analogous to the Access runtime)
[quoted text clipped - 19 lines]Well, if you develop code in VB and run it OUTSIDE of VB, it's a
stand-alone. It doesn't require the application used to develop it.
koolaidkidd1 via AccessMonster.com said:I understand that it cannot run without Access, but can it run in the
background instead of showing up first, so when I click on an icon, my
switchboard opens up a window by itself?
Have it your way, but there's no such thing as "an Access database created
in Developer version".
The Developer edition has always included Office Professional plus the
Access Developer Extensions (except, I believe, in Office 2000, when it
was
possible to purchase the ADE separately, and now Visual Studio Tools for
Office only includes ADE). In all cases, Access Developer Extensions will
not install unless Access has been installed.
You create the application using Access. Once you've created the
application, you use ADE to package the application together with the
run-time version of Access. As stated before, packaging the application
makes no changes whatsoever to the application.
The run-time version is the exact same executable (msaccess.exe) as the
"regular" version of Access. The only difference is that design features
have been turned off in the run-time version through literally hundreds of
registry settings. In other words, Access IS present when the run-time is
installed. If it weren't, the application wouldn't work.
This is similar to VB, by the way. An executable compiled in Visual Basic
will not work unless the VB runtime files are present on the client
machine.
Older versions of Windows didn't automatically include the VB runtime
files,
like WIndows XP does (and Vista will): it was necessary to create an
install
package to ensure that the VB runtime files were installed before the VB
executable could be used (The similarity ends there, though: the VB
runtime
isn't analogous to the Access runtime)
[quoted text clipped - 19 lines]Well, if you develop code in VB and run it OUTSIDE of VB, it's a
stand-alone. It doesn't require the application used to develop it.(no private e-mails, please)
koolaidkidd1 via AccessMonster.com said:I understand that it cannot run without Access, but can it run in the
background instead of showing up first, so when I click on an icon, my
switchboard opens up a window by itself?