When using NAVIGATOR to make a query for data, we have equal, not equal, and greater/less than options for patterns and values, so the glob-type method for pattern defnition using "?" and "*" as wildcards is acceptable because we can have "positive" and "negative" matching rules. However, when trying to use the same patterns in the SCRIPT interface, this becomes a problem because the way that GetChannel() and similar function is by looking for positive matches only, with no option to set a "negative" matching rule without post-processing the returned ElementList. That, combined with how little restriction is actually imposed by only a single-character and n-character wildcard, really impairs some functionality of the SCRIPT interface.
For instance, if there are channel groups of a certain type with that type denoted in the name, the pattern used for that supertype will also catch any subtypes using that pattern. A specific example being the pattern "_trans_<digits>" for transient logs that are grouped numerically with an unfixed number of digits in ascending order, and then "_trans_subtype_<digits>" for a subtype of the transient log that also requires a numeric suffix.
The problem arises when searching for all supertype transient-type groups but wanting to disallow subtypes. The pattern "_trans_*" (with a single asterisk for n-char wildcard at the end) catches both strings. The way I'm solving this currently is by using GetChannels() or similar to get the ElementList, then going back through that list to test the relevant strings against a regex pattern like "/\S*(_trans_)\d*$"/ig". This works just fine, but requires two patterns to be specified, a glob-type and a regex-type, for a single "query" through SCRIPT. This problem applies to group searching, channel searching, and is most problematic when you're using a .Name property for those objects where you may not have the full metadata content that would allow you to circumvent this problem.
Hello
Thank you for your request. We understand your suggestion but given that that just a few sponsors are supporting your entry and nearly no other customer asked this extension direct to us, we have decided to decline this suggestion. Nevertheless, we keep it in ore list of possible extensions however with a low priority and prefer to develop more frequently requested features instead. We hope you understand this.
Greetings
Walter