There was a post in the SWYMP about using the new PDM search syntax with the API. I’m re-posting my reply here so I can find it if I need it in the future.
I spent some time with this over the past couple of days and I can say with confidence that the API docs on this new search syntax are hot garbage and the example code is luke warm garbage. It also appears that the syntax itself may be buggy.
I had zero luck getting theIEdmSearch::FileName property working with the new syntax. The ‘special’ variable _Name only seems to work when used in conjunction with AddMultiVariableCondition, and even then it only works if you pass _Name in as one of the values of the string array poVariableNames. You can’t bind it in the condition String itself.
I used Claude to help me unpack this mess. I asked it to rate the documentation example on a scale of one 1 to 10, with 1 being terrible and 10 being very useful. The rating was 5.
I spent my time with Claude trying to get a very simple search to work: show me all the files in the vault that start with 437 and end with .sldasm or .sldprt. After multiple rounds of attempts with EdmSearch::FileName with no success, and multiple rounds of AddMultiVariableCondition based on what Claude (and I) thought should work, the only thing that actually worked was this:
string\[\] VarNames = { "_Name" };
search.AddMultiVariableCondition(VarNames, ":437* & {*sldasm | *sldprt}");
Given all the confusion and headaches, I asked Claude to estimate the target education level for the reader of the original search sytax docs. The reply:
=========================================
Based on the language and concepts used, I’d say the original documentation was written for someone with a graduate-level computer science or formal mathematics background — roughly a master’s degree level or higher in a technical field.
Specific clues:
Set theory language — phrases like “a pattern represents a multitude of values” and the way negation is described draws heavily from formal logic and set theory, which is typically not covered until upper-level university math or CS courses.
No examples in the core rules — the rules are stated as abstract principles without grounding them in practical use cases first. This assumes the reader can mentally map abstract syntax rules to real-world usage without hand-holding.
Assumed familiarity with formal grammar concepts — terms like “operands,” “distributive fashion,” “encapsulated expressions,” and “implicit data types” are used without explanation, assuming the reader already knows what these mean in a formal language context.
The negation section especially — the distinctions between !P, {!P}, !{P}, !{!P} are explained in a way that would be clear to someone with formal logic training but deeply confusing to anyone else.
Circular definitions — some concepts are defined using other terms that themselves haven’t been explained yet, which is a common (if frustrating) pattern in academic technical writing.
In short, it reads like it was written by a software engineer or computer scientist for other software engineers or computer scientists — and not necessarily ones who would be the primary users of the PDM system.
I then had Claude rewrite the API help docs on the Search syntax for the common person. I’ve attached it here:
SWPDM_Search_Syntax_Guide.pdf (20.1 KB)
