First, make sure your custom fields data is being indexed. You can check it using the manager
Windows Search index browser. If the data shows at these custom fields columns, then your custom fields are properly registered and the Windows Search indexer is correctly indexing these fields.
If when you type the field canonical name, e.g.
PDFShellTools.PDF.MyCustomField: (you can also just type the field name, i.e.
MyCustomField:), in the Windows Explorer search box, and the name don't turns blue, then this is a problem I'm also facing here. Somehow, the Windows Explorer/Shell fails to identify the name as a registered property. Sometimes you register a new custom field and the Shell is able to identify it, and sometimes not! If I define the same customs fields at another PC, I may get lucky and all get recognized by the Shell!
I suspect this is a bug in some component of the Windows Shell, that is used to parse the search in order to show the quick selectors by data type (e.g. the calendar), because If I query the index programmatically, i.e. by using the
ISearchQueryHelper::GenerateSQLFromUserQuery method, exactly with the same AQS expression that fails in Windows Explorer, it works just fine and I get a properly defined SQL expression (i.e. the custom fields names got recognized), I can then use to query the Windows Search index successfully.
I have even added a search box (available in the next release) to the above referred Windows search index browser, where the same AQS query that fails in the Windows Explorer (when in a situation where the custom property name is not being recognized), works just fine.
Right now I'm not aware of any workaround to this problem. If you get into any solution, please let e know. Should be a way to reset any registered properties list cache the Windows Shell is not updating properly.
