Open main form with an icon without Access

  • Thread starter Thread starter koolaidkidd1
  • Start date Start date
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.
 
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.
Click to expand...

You can't.
 
You can't make it an executable, but you CAN make it a stand-alone
which will run on a computer which doesn't have Access installed.

To do so, you need the Developer Version. There is no other way.
 
Just a point of clarification.

The Developer version does NOT create "stand-alone" applications. It doesn't
change the application in any way, shape or form. What it does is install a
royalty-free run-time version of Access, so that people who don't already
have Access installed can use the application.
 
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".
 
Well, first, most (likely none) of the people here work for Microsoft, and
we are volunteers.



I think it is VERY important to point out that the developer/runtime edition
of ms-access is not really a stand-alone system in a sense of creating a
..exe, or stand alone mde application.



Once the runtime is installed, then you can copy any mde, or mdb file to
that computer, and simply click on it. It well functions nearly the same as
the full version.



Further, that runtime can often be very large. For example, the a2000
runtime was up to 150 megs in size. (and also often required a re-boot of
the computer during install).



So, make no mistake here, that runtime is a full ms-access install, and the
only change is that design ability has been removed, and you need to
provide your own custom menus.



I can't tell you the number of times we seen people develop an application,
and then think that the developers edition produces a nice little .exe file
that you can easily download over the internet.



So, while the term "stand alone" is often used, it is OFTEN a miss leading
concept.



Since the runtime of ms-access is still a rather large application, it is a
stretch to call it a stand alone *without* given more information. (I
stress the issue of additional information).



It is also important to note that the runtime HAS NO special attachment to
the particular mde/mdb that you also (may) deploy to the users computer. In
other words, the runtime is a large install, and is SEPARATE from that of
your mde, or mdb that you plan to deploy on the computer.



By the way, we hope that the user split the application, even when in single
user deployments. The reason for this is now you can easily send updated
versions of your application to the users in the field, but their data will
NOT be over written. This is a another big reason as to why we split, and it
is one of deployment. This is especially so for runtime deployments. You
kind of have to split, else how can you send bug fixes and updates to your
clients using the runtime without overwriting their data? (and, we can't
modify the existing forms on their computers.since runtime does not allow
this. Hence, we just send then a whole new mde with the new code/changes).



So, it is a VERY good idea to clear up this issue, and also inform users
that the runtime for ms-access is NOT REALLY a stand alone version of their
mde/mdb file. It is not.



I am not trying to rag on you here, and the term "stand-alone" is often used
by many here in this newsgroup to refer to the ms-access runtime. (I'll bet
I used the term many times myself).



However, I think the term OFTEN does mislead people into what that runtime
actually is. So, you seem to take joy in laughing at, and seemly think that
the additional advice offered by Douglas is a "useless" and trivial extra
piece of information. However, you likely think this due to your lack of
knowledge and how the runtime actually works.



While it seems like Douglas was pointing out something of matter of trivial
semantics in the use of English, the ramifications of the runtime are
considerable, and the runtime is not a tiny little stand alone application
that contains the code of of a mde that you develop in ms-access. Your mde
remains seperate from the runtime system.



So, don't let your lack of knowledge cloud as to why additional information
about the runtime was pointed out. I seen WAY TOO many people here miss-lead
as to what the runtime really is.



So, sure...call it stand-alone..but, one should point out it really is
not..and you still are saddled with a large ms-access install. Note that the
runtime size for a2003 is now a more reasonable 34 megs in size (+ your mde
that you also copy to the pc).
 
I'm curious as to what your definition of "stand-alone" is, then.

--
Doug Steele, Microsoft Access MVP

(no private e-mails, 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".
Click to expand...
 
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)

--
Doug Steele, Microsoft Access MVP

(no e-mails, please!)


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
Click to expand...
 
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)
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.
Click to expand...
[quoted text clipped - 19 lines]
Click to expand...
 
Are you asking whether you can have only your form appear, without Access
around it?

You can try the approach outlined in
http://www.mvps.org/access/api/api0019.htm at "The Access Web".

--
Doug Steele, Microsoft Access MVP

(no 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?
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)
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.
Click to expand...
[quoted text clipped - 19 lines]
(no private e-mails, please)
Click to expand...
Click to expand...
Click to expand...
 
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?
Click to expand...

Yes, set the startup options such that the database window is hidden and
your startup form is your switchboard.

Keith.
www.keithwilby.com
 
Holy Splitting Hairs, Batman!

So, by your definition, is ANYTHING "stand-alone"? I mean, they all
need DLLs or EXEs or something that is packaged with them. If they
come with an installer, does that disqualify them?

Seriously, man. Some people just try to make things WAY too
complicated to make themselves feel superior. If it doesn't need
Office Professional with the full install of Access, anything packaged
with ADE is stand-alone. No need to drill down to the number of
registry keys that are effected in order to qualify to become a
stand-alone.
 
Kind of a good thread here ... heavy and light.

Have a buddy that writes assember code apps ... he says they are on
their own.

I just want to say big thanks to you people ... you have saved my bacon
big time over the last few weeks.

I put my programer's cap on this summer for the first time in three
years and it comes off this fall.
 
Back
Top