To give you a concrete example, if you use Foxit:
So to translate this:
Code:
"…Foxit Reader.exe" "C:test.pdf" /A page=5
The VFP equivalent is
Code:
RUN /N "…Foxit Reader.exe" "C:test.pdf" /A page=5
In general, if you want to do automation I'd rather opt for AutoIt:
In itself it's ja programmer tool, not an intuitively usable application. It's mainly a scripting tool for automation and so you start from zero with learning the AutoIt scripting language, but you find a very active community managing very many automation tasks you never thought of automating. You're better off using that than VFP for automation, especially if it's not OLE automation.
I advocate for this, for a simple reason, anything you can do from VFP to cause something in the external world is mainly three things:
a) CREATEOBJECT() of OLE automation servers, mainly Office applications or other OLE automation servers like Wscript.Shell
b) ShellExecute(), after you declare that Windows API function
c) RUN /N some.exe parameters
b) and c) are even quite equivalent in that respect and do quite the same, i.e. you can do most anything with RUN that you can do with ShellExecute. ShellExecute just has one little edge over what RUN /N offers with doing things with other verbs than the default "open", like "print". But there is nothing like "open page 3" to use as a verb, so you depend on the specific PDF viewer EXE to have command line options that allow specifying a page.
There are a few more things, like DDE, but that would be like talking about making fire with flint stones. The only thing that DDE offers is sending commands to an already running executable aka process and that in itself is something VFP can also do, but I fear I don't know even only one PDF viewer that has a DDE interface to send DDE commands to it. There's more in other usual interface like ODBC, interprocess communication, etc, but all these things are either specific to only certain types of connection/queries and even less probable to be offered for external control of PDF viewers.
Last not least, as Mike's sample shows, which I file under OLE automation, the actual automation doable is emulating what a user would do, i.e. what keys he would press. It often has its difficulties in timings, it's not the first thing I'd try, but if it's the only way of automation, then it can be done better with autoit than with wscript.shells' Sendkeys() method, which closes the circle to recommending autoit, unless you find the command line option for your PDF viewer or use Foxit now you know it offers that option. I guess Acrobat Reader will also have a similar command line option and other PDF viewers, too, as it's a natural functionality.
What's a limit of command line options like that of Foxit is that you don't control where and in what size the Foxit reader starts, so you only have limited control. Autoit very much specializes on controlling windows, so that aspect is easier to control. Not that you can't use API functions to control windows (forms) in VFP, too, but then that's still easier to do with autoit.
Chriss