PDF-ShellTools > Bug reports

PDFShellTools under limited account

<< < (2/3) > >>

hhcc:
The 32 version of xplorer2 does not crash with PDFShellTools, only the 64 version does. That will work for me for the time being.

Thank you for your prompt response,

A happy customer.

hhcc:
It is PDFShellTools's after all.

I use w7x64 but PDFShellTools installs in "Program Files(x86)" instead of "Program Files". The default value of

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\PropertySystem\PropertySchema\0002

points to

%ProgramFiles%\PDF-ShellTools\PDFShellTools.propdesc

but that file obviously does not exist. Windows Search Service (WSS) tries to index meta-data using that schema that cannot find. Since WSS breaks, OneNote tries to repair it. It does so by disabling PDFShellTools column handling (reverting to a existing schema).

The solution:

I copied the folder from "Program Files(x86)" to "Program Files" and I let OneNote repair WSS. OneNote and PDFShellTools work together now.

RTT:
That registry key is created by the Windows API itself, function RegisterPropertySchema from the IPropertySystem Interface, when registering the property schema. The use of that environment variable "%ProgramFiles%" for the property description schema path seems to be wrong, because such variable maps differently if expanded by a 32-bit or 64-bit application. I have no idea why the API uses an environment variable for that, and not the passed plain path (probably a bug?).
PDF-ShellTools call the RegisterPropertySchema function from a 32-bit application. Interestingly, if called from a 64-bit one, that key changes to "%ProgramFiles% (x86)\PDF-ShellTools\PDFShellTools.propdesc", which is also wrong if expanded by a 32-bit application, that will get "C:\Program Files (x86) (x86)\PDF-ShellTools\PDFShellTools.propdesc"

I haven't read any info, in the property system documentation, about the need to have the property schema file duplicated to make it accessible by 64 and 32 bit applications/shell extensions. Do have any info about that?

Another question that remains is why that OneNote privilege elevation tool (ONELEV.EXE) is reading that key anyway. It is using an API function for that (and what), or is reading it directly (and if yes, it is a wrong method)?
I ask this because the property schema seems to be correctly registered this way, with both 32-bit and 64-bit applications able to enumerate/access theses PDF-ShellTools custom properties.

What happen with OneNote if you remove that copy of the PDF-ShellTools folder from the "C:\Program Files\", and change that registry key to "C:\Program Files (x86)\PDF-ShellTools\PDFShellTools.propdesc" ?

hhcc:

--- Quote from: RTT on February 05, 2011, 11:40:27 PM ---I have no idea why the API uses an environment variable for that, and not the passed plain path (probably a bug?).

--- End quote ---
Feature you mean  ;)


--- Quote from: RTT on February 05, 2011, 11:40:27 PM ---I haven't read any info, in the property system documentation, about the need to have the property schema file duplicated to make it accessible by 64 and 32 bit applications/shell extensions. Do have any info about that?

--- End quote ---
Nope


--- Quote from: RTT on February 05, 2011, 11:40:27 PM ---Another question that remains is why that OneNote privilege elevation tool (ONELEV.EXE) is reading that key anyway. It is using an API function for that (and what), or is reading it directly (and if yes, it is a wrong method)?
I ask this because the property schema seems to be correctly registered this way, with both 32-bit and 64-bit applications able to enumerate/access theses PDF-ShellTools custom properties.

--- End quote ---
It has to do with the indexing service. I guess OneNote uses it to extract metadata from pdf files embedded in its own ".one" files.

What do you mean by "this way"? When I check Control Panel->Indexing Options->Advanced->File Types->.pdf, I get "Registered IFilter is not found". I know that the property schema is not the same thing as the IFilter, but I understand that they are both related to column handling.

Before installing PDFShellTools, I had installed "PDF fixes for 64 bits" and "Adobe PDF iFilter 9 for 64-bit platforms". This last one was supposed to give me the option of searching inside pdfs (I am using Copernic now) and be useful with Adobe's column handler.


--- Quote from: RTT on February 05, 2011, 11:40:27 PM ---What happen with OneNote if you remove that copy of the PDF-ShellTools folder from the "C:\Program Files\", and change that registry key to "C:\Program Files (x86)\PDF-ShellTools\PDFShellTools.propdesc" ?

--- End quote ---
I'll try it in a couple of weeks, so far I got it working with the extra copy. Anyway, I have so many programs dealing with pdf's that it would be difficult to pin to the

RTT:

--- Quote ---It has to do with the indexing service. I guess OneNote uses it to extract metadata from pdf files embedded in its own ".one" files.
--- End quote ---
Probably, but I don't see why the OneNote has to use a different method than the provided by the Windows API itself, that, if used, is able to correctly interface the PDF-ShellTools property handler, from both 32 and 64 bit processes.


--- Quote ---What do you mean by "this way"?
--- End quote ---
With that "%ProgramFiles%\..." path.


--- Quote ---When I check Control Panel->Indexing Options->Advanced->File Types->.pdf, I get "Registered IFilter is not found".
--- End quote ---
I don't have any IFilter for PDF's installed, and the filter description I get there is "File Properties Filter"


--- Quote ---I know that the property schema is not the same thing as the IFilter, but I understand that they are both related to column handling.
--- End quote ---
Both the property handlers and IFilters can provide access to properties and full text content, and a registered property is not necessarily registered as column. Can be used by the Windows Search, but not show as Column.
You can get extended info here:
http://msdn.microsoft.com/en-us/library/aa965717(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/bb266532(v=vs.85).aspx

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version