How to use a wildcard when opening an executable file with StrProg

[Nick Cooper]

I am using the following code to open up Acrobat Reader:

strProg = "C:\Program Files (x86)\Adobe\Reader 9.0\Reader\AcroRd32.exe"

which works fine, but on non-Windows7 computers the route is slighty different, also it is possible that a user may have an earlier version of Adobe. Is it possible to insert a wildcard in either or both of the 1st and 3rd directories to make display of a PDF independent of operating system and program version?

Nick

[Oralloy]

Nick,

What would the system do, if it encountered conflicting versions of Acrobat on the system? Pick one, and hope it was the correct version?

You might look, instead, in the Windows registry under one of the adobe entries to find the current version.

On my system, I searched for acrobat and found the following handle, from which you might be able to extract the executable name.

HKEY_CLASSES_ROOT\acrobat\shell\open\command

Again, on later version Windows systems, if you want to display a .PDF (or other acrobat) file, and the "reader" is registered, you should be able to just "execute" the file, and the system will do the rest for you. Mind, I haven't tested this, but you might want to give it a quick test.

On non-windows systems, I'm not certain what you'll need to do.

Luck!

[NeoPa]

If you'd like to access Registry Values from your database code there is some code for that available in Module to Read From the Windows Registry.

[Nick Cooper]

This routine opens Acrobat Reader and then the stored PDF of the invoice report applying to the selected record. As the paths to AcroRd32.exe vary (ie "\Program Files (x86)\" for Windows 7 and "\Program Files\" for XP and Vista) then I want the database to be able to function on different operating systems without the user having to amend the path to suit. Making the first directory (or even the last part of it) a wildcard would achieve that, if it's possible.

[ADezii]

I feel as though Oralloy had the right idea in Post #2. If your sole purpose is to Open *.pdf Files, and Adobe is the Registered Application for that File Type Extension (*.pdf), you can bypass executing the Adobe Executable and Execute the actual File or Path to the file itself. If you would like to see how this is done, just let me know.

[Oralloy]

Nick,

Were you using Perl, I'd say "glob the path"; however, this is in VBA.

You can still write the code to do path searches, but it's really not the happy way to go.

Also, there are folks (like me) who have tools mostly installed on a secondary "software" disk as part of their management technique.

So, if you're sticking with Windows systems, just execute the .PDF file. If you have to deal with Macintosh or Linux/Unix, then just execute the program name and trust that the user has his path set up correctly.

Cheers!

[Nick Cooper]

Thanks ADezii. Yes please!

Nick

[NeoPa]

Nick,

It's not clear that you've read the two posts prior to your response. Certainly you seem to revert to a position which is incompatible with the information posted therein.

In post #2 it is made clear that using a wildcard would make no sense. You need to get your head around this before proceeding. It's not that we have no code for it. It simply makes no sense.

Moving to post #3, there is information there that will enable you to discover exactly where the executable is found by accessing the registry. Without the facility of a wildcard in the name (which we now know is a done deal), this appears to be the next logical step, assuming you bypass the even simpler one of simply executing the PDF file itself and relying on the PC's Association setup to find and execute the reader.

If there is something we are not aware of that makes this inappropriate for some reason, then you should share that (technically it should have been part of the original question of course). Merely repeating your original position as if no-one had responded already, just gives the impression you haven't bothered to read the replies.

[ADezii]

The Demo Code that I am going to post is the most basic, simplest, 4-step approach for Opening/Executing a File based solely on its Extension (*.XXX). Is you wish to expand on this basic concept, we can at a later time.

1. Copy-N-Paste the following API Declaration into a 'Standard Code Module':
   

   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

2. Copy-N-Paste the following Code to wherever you deem appropriate:
   

   Dim strFile As String
   Dim lngErr As Long
   
   'Edit this:
   strFile = "C:\Dezii\KC Benefits.pdf"  ' the file you want to open/etc.
   
   lngErr = ShellExecute(0, "OPEN", strFile, "", "", 0)
   
   'Optionally, add code to test Value of the lngErr Return Value

3. Substitute your own Absolute Path to the *.pdf to be opened for "C:\Dezii\K C Benefits.pdf". This Value can be a Constant, Literal, pointer to a Control on your Form, etc.
4. Execute the Code - The File specified in strFile will be opened.
5. Any questions, feel free to ask.

[Oralloy]

Dezii,

Thanks for providing a good, working example. I think that'll get Nick over the hump for windows.

[ADezii]

Your welcome, at least for Windows! (LOL) Any non-Windows based OS, old Nick is on his own! (LOL)

[Oralloy]

Nahhh, not really

std::string command("acrobat ");
command = command + "/usr/local/Oralloy/mydoc.pdf";
system(command.c_str());

[Nick Cooper]

My apologies NeoPa, but you are attributing greater knowledge and experience to me than I merit. That is why it was not apparent to me prior to my #4 that the wildcard option was dead in the water. I know nothing about Registries and have alway been advised to steer clear of them if I'm not sure what I'm doing.

I did open up your recommended module in #3 but did not understand enough from it to proceed. Yes I should have replied to that effect but, as you no doubt gather, I'm new to these messaging systems and the protocol that applies, although I have every reason to be grateful for the things I have learned from this one (and you) so far.

I will hang slack for a day or two now and try to get my head around the further additions that have come along. For sure, executing the pdf directly is the way to go and many thanks to ADeziiall and Oralloy for their inputs too.
Regards - Nick

[NeoPa]

A perfect response Nick :-)

For what it's worth, I think you've made a wise choice going with the associated application approach.

As for the Registry Reading code, and also the reliable advice you've received concerning playing with the registry, I would make two points that may help, and may even put things in a clearer perspective for you.

1. The code linked to need not be understood to be used. Copy it wholesale into a module and it will be available to use, regardless of how it works. You would only need to understand how to call the RegRead() function. I've only just realised that I haven't explained that very well in the article and it could do with an update (Ooops).
2. Reading Registry values is not dangerous. Updating them in any way is definitely to be avoided unless you really know what you're doing, but reading them is pretty harmless (I can't think of any scenario where that may cause any problem).

PS. The article has now been updated so may be more use for those previously couldn't even see where to start.

[Nick Cooper]

Thanks Oralloy. Are you saying that if I place this code directly into the class module for the form from which I want to be able to double-click the chosen record, it will execute the PDF? The path that I currently use is:
"C:\Wheelbase\I nvoices\" & Me!Account & "-" & Me![Inv No] & ".pdf"
which you will note also imports two other variables from that record into the filename. How would that map into your middle line of code, forward slashes, etc?
Thanks
Nick