Open Adobe Quicker

[Katherine Lepley]

I have a program that searches for AcroRd32.exe on the user's computer, then it is to go to a network drive and open a pdf. Problem is, AcroRd32.exe is not in the same directory on every one's computers. Somertimes it's in the root of c, other times in program files, etc. When the program is run, it finds the file to open, but takes a long time to open it because it searches for Adobe too long. Below is the code we are using. If anyone can offer insight on how we can get it to open faster, please advise! Thank you!

LOCAL lCmd$
GetShortPathName lFilePath$ & CHR$(0), lOpenFile, SIZEOF (lOpenFile)
REPLACE ".pdf" WITH "" IN lFilePath$
lFilePath$=lFilePath$+".pdf"
lOpenFile=$DQ+lFilePath$+$DQ
gfType="AcroRD32.exe"
gStartPath="C:\"
StartAction
lAdobePath$=gPath$+"AcroRD32.exe"
CLOSE
ERRCLEAR
OPEN gPath$+"AcroRD32.exe" FOR INPUT AS #1
IF ERR THEN
MSGBOX "Adobe is NOT Installed! Contact IT!", %MB_ICONINFORMATION OR %MB_OK,"Adobe Reader"
END IF
CLOSE
lCmd$=gPath$+"Acrord32.exe "+lOpenFile
lResult&=SHELL(lCmd$,1)
IF lResult&=0 THEN
gAns&=EZ_Msgbox("OI","PDF ERROR!!! The PDF is missing! You can not proceed!"+$LF+lOpenFile+"{S}","Find PDF","OK")
END IF
EZ_UnloadForm "SPLASH"
CLOSE #100
EXIT SUB

[Chris Holbrook]

Problem is, AcroRd32.exe is not in the same directory on every one's computers.

suggestions:
a) re-install it in the same place on every computer b) store its location in a file on every PC in a conventional place / in an environment variable / in the register

[Michael Mattias]

Current way = Hard way?

LOCAL szAcroRead AS ASCIIZ * %MAX_PATH
OPEN "~dummy.pdf" for output AS #1
CLOSE #1 

iRet = FindExecutable ("~dummy.pdf", BYVAL %NULL, szAcroRead) 
KILL "~Dummy.pdf"
IF iRet > 32 THEN 
    CreateProcess       '"(program name) szAcroRead   fileofInterest  options"
    SHELL 
    ShellExecuteEx

Or, just ShellExecute "open", filename.PDF.

That will use whatever program is defined as the 'PDF' program on user's system.


MCM

[jcfuller]

Current way = Hard way?
[code]
Or, just ShellExecute "open", filename.PDF.

That will use whatever program is defined as the 'PDF' program on user's system.


MCM

And the lucky ones will have Foxit PopUp!

James

[Katherine Lepley]

Thank you Michael! It worked!

[Paul Franks]

And the lucky ones will have Foxit PopUp!

James

And the really lucky and smart ones will have PDF-XCHANGE VIEWER pop up:

http://www.docu-track.com/home/prod_user/PDF-XChange_Tools/pdfx_viewer

[Cliff Nichols]

I think you guys missed the point. (Or know something I don't)

just ShellExecute "open", filename.PDF.

will open your default program as it is registered with windows to be what you want to open it with (if you look through your filetypes setttings)

One "Hidden Gem" I did get from this was...what if you want to find out what the default program is? (THANK YOU MCM as I did not know this api existed)

#COMPILE EXE
#DIM ALL
#INCLUDE "Win32Api.INC"

FUNCTION PBMAIN () AS LONG

LOCAL szAcroRead AS ASCIIZ * %MAX_PATH
LOCAL lRet AS LONG
OPEN "~dummy.pdf" FOR OUTPUT AS #1
CLOSE #1

lRet = FindExecutable ("~dummy.pdf", BYVAL %NULL, szAcroRead)
MSGBOX szAcroRead
KILL "~Dummy.pdf"
'IF lRet > 32 THEN
'    CreateProcess       '"(program name) szAcroRead   fileofInterest  options"
'    SHELL
'    ShellExecuteEx
'end if
END FUNCTION

and as you can tell only took a few seconds to change from MCM's post to a usable program.

Nice lil nugget of knowledge for troubleshooting a system I would think

[Paul Franks]

I think you guys missed the point. (Or know something I don't)

Point not missed, merely adding value - there are alternatives to Adobe Reader that offer much more functionality or performance, which are also free.

One "Hidden Gem" I did get from this was...what if you want to find out what the default program is? (THANK YOU MCM as I did not know this api existed)

Not so hidden, a quick forum search for FindExecutable shows 49 previous posts going back to 2000. A couple of them are almost line-for-line the code posted above.

[Cliff Nichols]

One "Hidden Gem"

Not so hidden, a quick forum search for FindExecutable shows 49 previous posts going back to 2000. A couple of them are almost line-for-line the code posted above.

Yep still "Hidden Gem" since the definition of the word, is "One that is in front of you, but you can not see"... either by ignorance, obscurity, or not knowing enough to how or WHAT to question

aka FindExecutable makes perfect sense...but unless I know the api exists...I have to explain what I am looking for until someone offers a nugget of "Yep...just look here"...and blamo...there it is in front of me all the time

[Chris Holbrook]

... "Yep...just look here"...and blamo...there it is in front of me all the time

This forum really needs a keyword/phrase index as previously suggested. I thought that PB, Inc were doing something about it but it must be way down their list. Meanwhile we all (well those who need to, anyway!) put in far more time searching than is necessary. I had the same experience today, once I knew the answer, I could find the questions.

[Paul Franks]

At least the search function works now with the new forum SW. Remember when it didn't?

[Michael Mattias]

>At least the search function works now ....Remember when it didn't?

How quickly we forget!

[Cliff Nichols]

I like the search
It could be a bit smarter, but then again so could POFFS (razzing grin)

Nothing is perfect, but once I know the command or function I can do a search from "Invalidate Listbox" to "Invalidate" to "Invalid" until I get some hit that shows me...."Yep, you are NOT the 1st one to try this" and alleviate your hours of google, and pb, and any other search wondering why "Such a SIMPLE concept, could be so HARD to find a working example"

99% of the time....once I find the one "KEY" word that strikes a chord with me, I look around for it, and sure enough by the end I scratch my head wondering "Why the HELL did MSDN not just say that???!!!!!" because you did not know how to ask the question beyond what the goal was you were trying to achieve.
It always seems to be, that once I find it...its easy....Finding I am not asking the right question...now THAT is hard

(one thing that cracks me up is when I see a question similar I asked 6 months ago, I re-read, and my knowledge now vs then, and 20-20 hindsight....."WHYYYYyyyyy did I not get it, when it was pointed out in front of me????")


All in all....I do not think its low on the PB list, but I think if someone hired to put SDK documentation into PB Help file examples would go a LONNNNNNNG ways towards mis-confusions *LOL*

[Michael Mattias]

I like the search ...It could be a bit smarter, but then again so could POFFS ...

.. and so could the searchers?

[Cliff Nichols]

.. and so could the searchers?

maybe...but not likely!!!!

Unless you know what key word you are searching for, all you can do is search for the concept, then gather key words that appear in that scope (if you are a smart searcher), and then narrow down from there until you have the correct hit.

I am not blaming the search engines for anything cause they are excellent, I just wonder if they could be better? or if there is a better technique for searching when all you know is the concept you want to do, but no CLUE any of the key words to search for????

And of course when all else fails.....post in the FORUMS!!!!! because someone somewhere must have run into the problem you are having, and maybe a way to fix it, find it, or give you a leg up on what you are trying to achieve.

Thats what I love about PB....what you don't know, or how to ask, someone can still help

[Michael Mattias]

>This forum really needs a keyword/phrase index as previously suggested

And who decides what those key words and phrases are to be?

e.g., what would you suggest as "keywords" or "phrases" to best describe the purpose and use of the FindExecutable function?

"Find default program by filetype" maybe? How about "open file using program registered for a particular file extension?" Or maybe just "find default program by file extension?"

All the above are perfectly valid uses for FindExecutable. Of course, case 2 (open the file), now you'd need additional links to SHELL (statement), SHELL (function), CreateProcess[AsUser] and ShellExecute[Ex].

Between the compiler's extensive set of features and the features provided in the WinAPI there have got to be at least sixteen ways to do anything.

MCM