Invalid Pattern string error in script

[klownboy]

Hopefully a quick question, I'm getting an error message when comparing variables. In developing an inputselect dialog, I need to compare two strings such that I can have the ones that match, pre-checked. One string of variables is a listing of all current user buttons CTBs and XY built-in buttons currently on the toolbar and the other string is a listing of "all" buttons available in XY also including the CTBs (some are not used). I've tried a number of different methods, but I receive and an "Invalid pattern string" error message. I believe it's due to the format of some of the strings yet they are identical. I've cross-checked that. The comparisons that don't have the ":" or "[" will work.

Code: Select all

Invalid pattern string
"CTB 13: [L-drag] Meta [R-drag] Set Wallpaper [L] Pic Thumbs [no TB] [R] Pic Thumbs [w TB]"  LikeI  "CTB 13: [L-drag] Meta [R-drag] Set Wallpaper [L] Pic Thumbs [no TB] [R] Pic Thumbs [w TB]"

So I ran a simplified test to see what was happening using this code. Quoting or not it fails.

Code: Select all

  $TB = "CTB 13: [L-drag] Meta [R-drag] Set Wallpaper [L] Pic Thumbs [no TB] [R] Pic Thumbs [w TB]";
  $UB = "CTB 13: [L-drag] Meta [R-drag] Set Wallpaper [L] Pic Thumbs [no TB] [R] Pic Thumbs [w TB]";
   if ($TB LikeI $UB) {echo they match; }
   else {echo "They don't match even though they are the same"; }

I've tried quoting the strings and using SC quote, and even tried RegexMatches but it fails when it's comparing a CTB that has characters like "[" and ":". Does XY fail when comparing strings which have some of thes characters like "]" or ":" ? Thanks,
Ken

[TheQwerty]

The right-side of the Like and UnLike operators accepts a pattern which can include wildcards, so XY is attempting to treat each '[...]' as a character class.

You need to replace '[' with '[[]' or use '==', '!=', or the Compare SC instead.


Why this causes an error instead of just matching with the wildcards I'm not entirely positive. My guess is that because you're using the case-insensitive version XY first converts both the string and pattern to lowercase and this causes the character classes '[l-drag]' and '[r-drag]' to become invalid since 'l' and 'r' come after 'd'.

[klownboy]

Thanks TheQwerty, that's why I couldn't get my original script line to work either which used "LikeI" to see if any one of the entire string matched like so...

Code: Select all

if ("$cur_user_buttons" LikeI $TB) {

With the above line, I got the pre-check marks on all the "matching" toolbar buttons, including the CTBs but only the CTBs without the "[" brackets. This would have been much quicker and with one less foreach loop. I did already try using "==" on the above sample and it did work. I'll have to try "Like" as well since they should be identical in every way. Thanks.

[TheQwerty]

I'll have to try "Like" as well since they should be identical in every way.

'Like' is not at all identical to '=='.

The former ('Like'/'LikeI') tests against a pattern and can be told to ignore case.
The latter ('==') only tests if both sides are the same.

If you only care about equality you may be better off hashing the string values and then comparing the hashes.
With dereferenced variables you could even go so far as to create a dictionary-like set of variables to make it easy to reference the CTBs by hash.

Code: Select all

$string = <<<STRING
"CTB 13: [L-drag] Meta [R-drag] Set Wallpaper [L] Pic Thumbs [no TB] [R] Pic Thumbs [w TB]";
STRING;

  $hash = hash('md5', $string);

  // Keep list of hashes - use to enumerate all CBs.
  global $HASH_CB_LIST;
  if (GetTokenIndex($hash, $HASH_CB_LIST,, 'i')) {
    echo 'Collision - hash is already in list.';
  } else {
    // Add hash - maybe a little overkill why bother with premature optimizations though?
    $HASH_CB_LIST = FormatList($HASH_CB_LIST . '|' . $hash, 'dents');
  }

  // Variable names cannot start with a number.
  // But the hash could so we add a known prefix.
  $prefix = '$HASH_CB_';

  // Store the definition string as $HASH_CB_<hash>
  $varName = $prefix . $hash;
  global *$varName = $string;

  // Store a new 'is_checked' field as $HASH_CB_<hash>_checked
  $varName = $prefix . $hash . '_checked';
  global *$varName = false;

  step;
  echo 'take a look at the variables now...';
  echo 'pretty cool huh?';

[klownboy]

Thanks once again TheQwerty. It looks like it's working fine using "==" with the two foreach loops. I just have to fine tune it to get the proper locations for SC "break" and SC "continue" within/after the loops so I don't have repeats, but the matches are reflected properly now. Good idea on the hash values (and yes that was quite cool) and also using gettokenindex. It looks like I could use SC gettokenindex without the hash values in this case as well with a line like this...

Code: Select all

if(gettokenindex($UB, "$all_tbs") != "0")

[TheQwerty]

It looks like I could use SC gettokenindex without the hash values in this case as well with a line like this...

Code: Select all

if(gettokenindex($UB, "$all_tbs") != "0")

Doubtful, the default value for the flags parameter treats the token as possibly having wildcards; putting you back at the problem with 'LikeI'. You'd likely want:

Code: Select all

if(gettokenindex($UB, $all_tbs,, 'i')) {
  // $UB is in $all_tbs
}

[admin]

Also note the brand-new option Configuration | Find Files & Branch View | Find Files | Enable extended pattern matching . Untick it and your problems are gone.

EDIT 20150316: The above is nonsense. That option ONLY affects Find Files.

[klownboy]

Good to know. Thanks Don. So that Find Files setting affects the comparison behavior when using LikeI /UnLikeI. So by disabling extended pattern matching, LikeI becomes similar or closer in meaning to "==". In a 'fresh' run it looks like the default is "off". Even so, we'd have to be careful in scripts since many may have it 'on' as I did.

[admin]

Good point. I will add it to SC setting and settingp.

[TheQwerty]

Also note the brand-new option Configuration | Find Files & Branch View | Find Files | Enable extended pattern matching . Untick it and your problems are gone.

What operators does this affect?

[admin]

#, !, [, ], and only in Find Files.

[TheQwerty]

Sorry I wasn't clear.

I know what wildcards it covers, but what scripting commands/operators does that option affect?

Like, LikeI, UnLike, UnLikeI, anything else?

EDIT: Although now I'm confused because it doesn't actually appear to affect scripting at all in 15.00.0109.

EDIT 2: Note I hadn't actually tested previously, just going off of this thread it sounded like that option changed the behavior of scripting commands/operators.

[admin]

It does not affect scripting. It only affects Find Files.

[TheQwerty]

It does not affect scripting. It only affects Find Files.

Then the following was not true:

Also note the brand-new option Configuration | Find Files & Branch View | Find Files | Enable extended pattern matching . Untick it and your problems are gone.

klownboy's issue was using Like/GetTokenIndex in a script so he can tick and untick this option all he wants and it won't fix his script or his number of problems.

Which is great news, because I was about to panic over how many scripts this could break but it only affects scripts which perform quick searches or load search templates containing the extended wildcards - which is a significantly smaller number.

[admin]

Uhm ... ... yes, that was nonsense.