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)
        Application.Quit

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.
rmkAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Jim Dettman (Microsoft MVP/ EE MVE)President / OwnerCommented:
See the following comment:

http://www.experts-exchange.com/Microsoft/Development/MS_Access/Q_28054927.html#a38973604

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

Jim.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Boyd (HiTechCoach) Trimmell, Microsoft Access MVPDesigner and DeveloperCommented:
I use this:

Shell and Wait
0
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.
0
Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

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

For self updating Front Ends I use the following:

see: http://www.btabdevelopment.com/ts/freetools


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).
0
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:
\\...\Setup\11.0\
\\...\Setup\14.0\
\\...\Setup\15.0\
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.
0
Boyd (HiTechCoach) Trimmell, Microsoft Access MVPDesigner and DeveloperCommented:
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.
0
Jim Dettman (Microsoft MVP/ EE MVE)President / OwnerCommented:
There is also Tony Towes AutoFE updater.  Used to be free but is no longer.  However it is still well worth the money.

http://www.autofeupdater.com/index.htm

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

Jim.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Access

From novice to tech pro — start learning today.