Access 2003 Shell and Have Shelled application wait for shelling application to end

When my Access 2003 application starts and  detects that a new version is available, it shells out to another Access 2003 application to install the new version. It does that with 2 lines of VBA code:
        Call Shell(RMK_EncloseString(strAccess) & " " & RMK_EncloseString(strSetupDbFQFileName) & " /cmd " & AppName(), vbMaximizedFocus)

The Shell statement sends a command line parameter which is the name of the application whose new version is to be installed. I want to add another command line parameter which is the handle of the access application doing the shelling. That part I know how to do.

However, when the Access application that has been shelled to starts, I want it to use the Sleep dll until the application specified by the handle parameter in the command line has ended. I know how to use the Sleep dll but I don't know how to use the handle parameter to determine when the calling application has terminated. I need it to wait because it needs to overwrite the first application which occasionally has not completed processing the Application.Quit statement.
Who is Participating?
Jim Dettman (Microsoft MVP/ EE MVE)Connect With a Mentor PresidentCommented:
See the following comment:

 Read that and the next couple of comments down for how to use with Shell()

Boyd (HiTechCoach) Trimmell, Microsoft Access MVPCommented:
I use this:

Shell and Wait
rmkAuthor Commented:
Shell and Wait is the wrong direction. I'm quite confident that JDettman has the right answer. I'll be testing it tomorrow.
Get 10% Off Your First Squarespace Website

Ready to showcase your work, publish content or promote your business online? With Squarespace’s award-winning templates and 24/7 customer service, getting started is simple. Head to and use offer code ‘EXPERTS’ to get 10% off your first purchase.

Boyd (HiTechCoach) Trimmell, Microsoft Access MVPCommented:
Sorry, I did not read your post close enough.

For self updating Front Ends I use the following:


FRONT-END AUTO-UPDATE ENABLING TOOL (Works for all versions 2000 and up)

Microsoft Access Front-End Auto-Update Enabling Tool - allows you to quickly add auto-updating to your front-ends (PLEASE NOTE: This tool is primarily meant for networked users that have direct access to the backend location). Revised file updated 06 Sep 2008

Documentation for the Auto-Update Enabling Tool

 FRONT-END AUTO-UPDATE ENABLING TOOL (version for secured database using mdw file)

Microsoft Access Front-End Auto-Update Enabling Tool (for secure db) - allows you to quickly add auto-updating to your front-ends that need to use a workgroup file and shortcut to open the database using that shortcut.  This version is courtesy of Tom Knight of the London Borough of Hillingdon (thanks Tom!).

Documentation for the TKnight version of the Auto-Update Enabling Tool is included in the above zip file.

FRONT-END AUTO UPDATE ENABLING TOOL (version for SQL Server/SharePoint).
Microsoft Access Front-End Enabling Tool (for SQL Server/SharePoint)
Documentation will be coming soon (5 Nov 2012).
rmkAuthor Commented:
the front end auto update enabling tool definitely looks slick. I have an extra complexity in that my applications must run in Access 2003, 2010, and 2013. So my version control mechanism uses a server folder structure like:
\\...\Setup\ which contains SetupMgr.mdb whose sole purpose is to detect the version of Access being used and then open Setup.mdb in one of the following paths:
Each of the above version paths contains the current version of the front end which can compile in that version of Access. Using # conditional compile variables helps me make sure it all works. Each version has to be kept in a non-compiled state because some Access service packs in some versions will cause errors on some workstations if the application is kept in a compiled state. The first time a new version the application gets installed on a workstation it re-compiles itself.
Because Access front ends sometimes become corrupt, the users have a shortcut to \\...\Setup\SetupMgr.mdb. This also let's them click a Re-Install button in the application for those cases when I have to issue a hot fix.
Also because I have several applications, SetupMgr.mdb accepts a command line parameter of the desired application name and passes that to the appropriate Setup.mdb which then knows which application to setup. If it does not receive an application name parameter it presents the user with a multi select list box of applications to choose for setup.
I guess i might be able to make it all work with the F-E-A-U-E-T, but what I've got seems to work pretty well for us.
Boyd (HiTechCoach) Trimmell, Microsoft Access MVPCommented:
Fortunately I have not run into the issues you have described.

I have several apps that are a Access 2003 MDE (front end) that work just fine in Access 2003, 2007, 201, and 2013.   I also have some in Access 2007 as mde and accde that work just fine in Access 2007, 2010, 2013. That are the 32 bit versions.  

 I have been able to use a single front end for all 32 bit platforms and recompile as a separate one for 64 bit office. I only need to have two pre-compiled (MDE/ACCDE) versions that get deployed. One 32-bit and one 64-bit.

Hopefully you can at least learn from the Auto update example I posted. It will show to have an access front end close and copy a new version of itself.
Jim Dettman (Microsoft MVP/ EE MVE)PresidentCommented:
There is also Tony Towes AutoFE updater.  Used to be free but is no longer.  However it is still well worth the money.

Well thought out, has been around for years, and handles a lot of special cases, including Citrix environments.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.