Groan: FindExecutable can fail on Win8+

[IdeasVacuum]

Well, FindExecutable() was a great way to test if a PDF Reader existed, but not any more. Windows 8.1/10 associates .pdf with the "modern interface" Reader, even if the Desktop version of Adobe Reader is also installed. So the following tried and trusted code doesn't cut it anymore:

Code: Select all

Procedure.i PdfReaderFind()
;#-------------------------
;Returns a value greater than 32 if successful
Protected     sTestFile.s = "test.pdf"
Protected          sDir.s = GetTemporaryDirectory()
Protected      sExePath.s = Space(#MAX_PATH)
Protected iReaderExists.i = 0

              If CreateFile(0, sDir + sTestFile)

                         CloseFile(0)

                        iReaderExists = FindExecutable_(sDir + sTestFile, #Null, @sExePath)

                        DeleteFile(sDir + sTestFile)
              EndIf

              ProcedureReturn(iReaderExists)
EndProcedure

Debug PdfReaderFind()

I imagine that 101 out 100 Users prefer the Adobe Desktop Reader over the 'Modern' Reader, which takes over your screen and generally behaves badly, so I don't mind my app telling the User that a PDF Reader can't be found, at least for now. I suspect though that 'Modern' Reader might evolve quickly to become 'only' Reader. Then what.......

[Michael Vogel]

Only have Windows 8.1, but here it works if an "app" has been associated to the pdf extension (I don't use the Adobe but the pdf viewer but a viewer from tracker-software) - the return code is 42 (sic!)

Code: Select all

Procedure.i PdfReaderFind()
	;#-------------------------
	;Returns a value greater than 32 if successful
	Protected     sTestFile.s = "test.pdf"
	Protected          sDir.s = GetTemporaryDirectory()
	Protected      sExePath.s = Space(#MAX_PATH)
	Protected iReaderExists.i = 0

	If CreateFile(0, sDir + sTestFile)

		CloseFile(0)

		iReaderExists = FindExecutable_(sDir + sTestFile, #Null, @sExePath)

		DeleteFile(sDir + sTestFile)
	EndIf

	If iReaderExists>32
		Debug PeekS(@sExePath)
	EndIf
	ProcedureReturn(iReaderExists)
	
EndProcedure

Debug PdfReaderFind()

Another approach would be to check the registry (see also here), the following simple code works for my configuration...

Code: Select all

ProcedureDLL.s ReadRegKey(OpenKey.l, SubKey$, Valuename$)
	hKey.l = 0
	KeyValue$ = Space(255)
	Datasize.l = 255
	If RegOpenKeyEx_(OpenKey, SubKey$, 0, #KEY_READ, @hKey)
		KeyValue$ = "Error Opening Key"
	Else
		If RegQueryValueEx_(hKey, Valuename$, 0, 0, @KeyValue$, @Datasize)
			KeyValue$ = "Error Reading Key"
		Else
			KeyValue$ = Left(KeyValue$, Datasize - 1)
		EndIf
		RegCloseKey_(hKey)
	EndIf
	ProcedureReturn KeyValue$
EndProcedure


Program.s=ReadRegKey(#HKEY_CLASSES_ROOT,".pdf","")
If Program
	Debug ReadRegKey(#HKEY_CLASSES_ROOT,".pdf\"+Program+"\ShellNew","Command")
Else
	Debug ": ("
EndIf

[Little John]

Same as Michael Vogel here on Windows 10:

PdfReaderFind() returns 42, and PeekS() inside the procedure shows the correct path to "PDFXEdit.exe" (PDF-XChange Editor from Tracker Software), whch is my default PDF program.

[IdeasVacuum]

I'm sure lots of people will install a desktop reader and assign the files to it, but not most people. Other apps are affected too. I think we need some sort of 'bridging' lib, desktop-to-modern. I avoid making registry enquiries for this sort of thing - it's not reliable information, an un-installed app can be reported as still being present.