How to use SysCmd(acSysCmdAccessDir) in code 1

[votegop]

I have the following code in a module:

Dim stAppName As String
stAppName = "C:\Program Files\Microsoft Office\Office\WINWORD.EXE C:\MyDir\MyWordDoc.doc /MMerge"
Call Shell(stAppName, 1)

If the user has Office XP, the path to the Office executables is changed, for example: C:\Program Files\Microsoft Office\Office10\WINWORD.EXE

Another post tells me I can use SysCmd(acSysCmdAccessDir) to return the path to the .exe. How do I use it in the above code to make my path less sensitive to the version of Office? I'm a VBA rookie, but can usually muddle through...

 

[jryan224]

votegop,
If and only if the user is using all the same Office products will getting the path to the main Office folder help you.

For example, if the user is using all XP Office then:

Dim stPath as string
stPath = SysCmd(acSysCmdAccessDir)

will give the directory path to the folder which contains msaccess.exe.

If all XP Office, winword.exe will be in the same folder. You can then use stPath to launch winword.exe.


The problem is if you are using a different version of Access than the version of Word. Our ouffice is supporting Access 97 apps and Access 2000 for backend to other apps. So my pc has both versions installed with Access 97 as default. I only have Word 2000. So gettng path to Access 97 will not give me the path to winword.exe.


I have not launched external apps from my Access97 apps; however, do you have to specifiy the path to winword? Usually .doc is associated with winword. So if you just open myworddoc.doc, wouldn't it automatically launch winword.exe no matter what version or where it was located.

Throwing out ideas you might investigate. If users have desktop icons to Word, could you get the target path? This would always assure you the correct path to whatever version of Word was in use regardless of Access version.

Although I did not give you a definitive answer, I hope this will help in some way.

Jdemmer

 

[votegop]

Thanks for the reply. I muddled around trying to contcantenate the variables and got it to work...almost. It seems to be hanging on the Word macro execution. It actually opens the Word document (cool - it found winword.exe), but says "invalid file name" after it opens instead of executing the macro (which performs a merge). Seem strange, since it works as discribed in my post above.

I used (remember, I don't really know VBA):

Dim stAppName As String
Dim stPath As String
Dim stCombinedPath As String
stPath = SysCmd(acSysCmdAccessDir)
stAppName = "WINWORD.EXE C:\MyDir\MyWordDoc.doc /MMerge"
stCombinedPath = stAppName & stPath
Call Shell(stCombinedPath, 1)

Let me know if I'm being obtuse. (-:

 

[votegop]

Sorry, I should have also added that I believe when using the Shell command you have to launch the .exe first (in response to your idea about coding directly to the .doc)

I don't have any idea how to extract the target path from a shortcut to use in a Shell command. I like the idea, but I'm clueless on that one.

 

[jryan224]

votegop,
Given your last code.

stPath would be something like - c:\programs\MSOffice97
stAppName = "WINWORD.EXE C:\MyDir\MyWordDoc.doc /MMerge"
stCombinedPath = stAppName & stPath

so stCombinedPath would be :
WINWORD.EXE C:\MyDir\MyWordDoc.doc /MMergec:\programs\MSOffice97
Don't your really want to end up with:
c:\programs\MSOffice97\WINWORD.EXE C:\MyDir\MyWordDoc.doc /MMerge

thus stCombinedPath is backwards? and requires a space?
stCombinedPath = stPath & " " & stAppName

Hope this helps,
JDemmer

PS. I can get commandline paramaters in Visual Foxpro6 but couldn't easily find a way in Access.

 

[votegop]

...ummm...errr...its backwards eh?...

Thanks Jdemmer. You got it. It did not require the space, but otherwise works beautifully! Most of my clients will be somewhat unsophisticated, and it won't be likely they'll have more than one version of Office installed. I'll just have to make sure I screen for systems like yours, so that I don't have conflicts.

But for simply working around hard-coding the path, this is great. Thanks again.

 

[votegop]

Ok, I have to ask just one more...

Do you know how to do the equivalent for a desktop shortcut? I guess it would be an environment variable or something like %officedir%. Obviously I'll have the same problem if the shortcuts I distribute are pointing to ../Office/.. instead of ../Office10/..

 

[jryan224]

votegop,
Sorry, no I do not know.

We have about 55 locations across the state divided in 10 regions. Each region has a technical support staff for all the hardware related stuff.

The technical support staff do the local stuff like the shortcuts. And for us to try and keep up the shortcuts is not pratical since each location may use a different drive letter.

But to understand, what shortcut are you talking about? The application (module) you are working on?

Jdemmer

 

[MichaelRed]

to unify (and simplify) your life, you COULD use UNC naming convention in setting up how users in the field accessed the various functions. Then, the shortcuts should at least approach commonality. Which (then) could become a centralized function. (hmmmmmmmmmm, perhaps it wouldn't simplify your life?)

MichaelRed
m.red@att.net

There is never time to do it right but there is always time to do it over

 

[votegop]

Jdemmer/MichaelRed:

I am referring to the command line in a desktop shortcut similar to: "C:\Program Files\Microsoft Office\Office\MSAccess.exe" "c:\Myfolder\MyFrontEnd.mdb" /user /wrkgrp "c:\Myfolder\MyMdw.mdw"

If I distribute a desktop shortcut icon with this command line, and the user is using Office 2002, it will not find MSAccess.exe because it should have been "C:\Program Files\Microsoft Office\Office10\MSACCESS.EXE" "c:\Myfolder\MyFrontEnd.mdb" /user /wrkgrp "c:\Myfolder\MyMdw.mdw"

I'm just wondering if there is a work-around to having to have two different installation packages (which include my .mdb and shortcuts): (1) for AC2K users, and (1) for AC2002 users.

 

[MichaelRed]

Hmmmmmmm,

Actually, it could easily get much worse than that. Unless you are in a VERY tightly controlled (corporate) environment, the installation process permits the selection of alternate installation 'folders', which - in turn throws the entire question of the path to a specific executable into chaos at least as having a static link which is included with the setup. Obviously, the path to the exe CAN be derived, as many (or most?) commercial (shrink wrap) programs generate shortcuts to the exe during installation - and these generally are to the actual installation path. On the other hand, these link generators are also (obviously) doing more than copying a few files to 'somewhere'. You might look into the details / requirements of "Setup" (a.k.a. "Package and Deployment) to see if it is something you want to use. I'm sure that it would require additional "code", but not aware of how much more to generate your fully customizeable Link.

MichaelRed
m.red@att.net

There is never time to do it right but there is always time to do it over