UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
> Using Shell Or Shellexecute For Non-ms Programs, With Arguments, Office 2007    
 
   
ipisors
post Apr 16 2012, 04:27 PM
Post #1

UtterAccess Certified!
Posts: 6,942
From: Arizona, United States



I want to learn how to use Shell or ShellExecute (or similar) in VBA to launch a program plus supply arguments to specify things to that program. I don't understand how a developer can know or find the specific syntax to launch a program with "specific actions", especially if it's not even a MS product. For example, I have seen .bat files that do exactly what I'm used to doing with VBA: 1) specify the program file path (C:\Program Files\Program.exe), plus 2) the file name to launch (C:\Folder\File.PDF or what ever it is).

However, now I've also been exposed to .bat files that go much farther than that. They add on to that all kinds of specific arguments to tell the program to do more specific things with specific parameters.

How does this get developed? Obviously short of asking the person who created the .bat file, I'm wondering if UA can point me in the best learning direction. I'd rather do this because I am looking for expert direction to point me in how this information is ascertained in general for people using these methods to automate a non-MS product.

For example, right now I'm seeing .bat files that automate a program called Monarch Pro. The bat file isn't complicated, maybe 5-6 lines of code editable in Notepad. It specifies the program path, then tells the program to open a specific monarch "project" file (ending in .xprj), and then adds 2 or 3 more arguments - like "export this specific table, with this specific filename, then close", etc. etc. So how did this person create a bat file (or how could I do similar in VBA), and know what specific names and syntax to use for these arguments, without being the person who created Monarch pro?

What stumps me is, how does the person coding this KNOW what those calls are to make to the program? Do you have to dig into the .dlls of the program, or somehow backwards engineer the .exe, or what??

I don't know if this conversation relates to the whole world of API's in gneral, or not.

Thanks in advance!

This post has been edited by ipisors: Apr 16 2012, 04:29 PM
Go to the top of the page
 
+
doctor9
post Apr 16 2012, 04:35 PM
Post #2

UtterAccess VIP
Posts: 9,304
From: Wisconsin



Isaac,

You seem to be taking this from a "hacker" point of view, as if there's no information freely available to you on software you've purchased. (IMG:style_emoticons/default/smile.gif)

I would say the best strategy is to:
1. Read the documentation that came with the software.
2. Ask the developer of the software (via their tech support) for information on command line arguments/switches.
3. Attempt to run the program from a DOS prompt with switches like "?' or "/?" to see if they respond with a help file that lists various arguments.

For example, in the 90's, I seem to remember if you ran PKZIP from a dos prompt with a "/?" or a "-?" switch, you'd get a screen full of text showing the various arguments you could use. Heck, you could even do that with some old DOS commands, like DIR. Even more info was available in the documentation that came with the program.

Hope this helps,

Dennis
Go to the top of the page
 
+
ipisors
post Apr 16 2012, 04:53 PM
Post #3

UtterAccess Certified!
Posts: 6,942
From: Arizona, United States



Ha ha, sorry Dennis if I did that....I guess it just shows how confused I am about it. Could be I am making the wrong assumption, but it seemed like what happened was that someone knowledgeable about programming--but not from the vendor company--wrote all of these command line type of things, and I thought maybe there was some "standard" way to research it. Ok, so basically it comes down to relying on documentation from the vendor I guess?

I guess at the end of the day I am always curious about things like API's and such. I am grateful to the internet and the fact that I can google "an API to do such-and-such" and someone somewhere has probably already posted it, but I find that just copying and pasting other people's code really keeps me from learning, so I always find that the better question is, how did THAT person find out how what the API was? And especially from just a random program on their computer that I don't think they had any independent familiarity with, but they seemed to know just what to do to write what looked (in .bat) , almost identical to vba's ShellExecute command, with 3 or 4 additional arguments.

But OK...I probably need to just accept that it is a combination of documentation provided with the software as well as your other suggestion about help that may display with DOS commands.

Thanks Dennis! I know this was a very vague question, sorry about that!

This post has been edited by ipisors: Apr 16 2012, 04:54 PM
Go to the top of the page
 
+
GlenKruger
post Apr 16 2012, 06:43 PM
Post #4

Utterly Crispy UA Forum Administrator
Posts: 7,100
From: Edmonton,Alberta,Canada



CODE
Public Declare Function ShellExecute Lib "shell32.dll" Alias "ShellExecuteA" (ByVal Hwnd As Long, ByVal lpOperation As String, ByVal lpFile As String, ByVal lpParameters As String, ByVal lpDirectory As String, ByVal nShowCmd As Long) As Long


This is the actual call to the function.

An example to open a program and run it would be:

CODE
ShellExecute 0, "Open", CurrentProject.Path & "\RemoveDriveByLetter.exe", strMyDrive, "", 0


The parameter I am passing is strMyDrive which the program actually requires to run.

This is being done in Access 2007 though.

Hope this helps some what.

Oh by the way I wrote the program that is being opened so I knew what parameter to pass it so it all boils down to in your case getting info from manufacturer of program.
Go to the top of the page
 
+
ipisors
post Apr 18 2012, 11:00 AM
Post #5

UtterAccess Certified!
Posts: 6,942
From: Arizona, United States



Ok, thanks Glenn. My confusion stemmed from the fact that a person who seems to be familiar with programming, but not necessarily with the program they're trying to manipulate, quickly wrote a few lines (with 3 or 4 extra parameters) to shell out the launching of the program as well as several actions within the program after that.

However, I must be mistaken - they must have had to go get that information from the vendor, manuals, or somewhere that I didn't realize.

I thought maybe there was some commonly regarded way to examine the application extentions or DLLs or something of just "any" program and discover how to command it. I guess that is not the case. (IMG:style_emoticons/default/smile.gif)

thanks all!
Go to the top of the page
 
+
GlenKruger
post Apr 19 2012, 08:27 AM
Post #6

Utterly Crispy UA Forum Administrator
Posts: 7,100
From: Edmonton,Alberta,Canada



I would ask the vendor if there is a command line statement to open the program.
That would be what you would base your shell execute statement from.
Go to the top of the page
 
+

Thank you for your support! Reply to this topicStart new topic

Jump To Forum:
 



RSS Go to Top  ·  Lo-Fi Version Time is now: 25th May 2013 - 09:21 PM