@ ptp option 1 & 2 where giving the error message. As mention the "~2" did the magic. by the way what is the #2 for?

@ david

You're right, we can start the SW with the data file directly in the same command.

EX: Exec("C:\progra~2\RoboRealm\RoboRealm.exe","C:\Users\gilles\AVM\face_rec.robo")

read my previous post on DOS short names

before windows, DOS only supported folders or file & folder's names with max 8 characters and extensions with max 3 characters.

to allow old applications (DOS) and other legacy you could access a big file name or path name via an equivalent short path name

so

"c:\progra~2" is the equivalent for "C:\Program Files (x86)"

the short name varies per system, windows by default has 2 paths

"C:\Program Files" => "progra~1" "C:\Program Files (x86)" => "progra~2"

at least those two seem to be always present.

I forget the term, but this feature is included to allow windows to use old style 8.3 character names that were prevalent when DOS was around. It is required also for some storage solutions and such so it just keeps hanging around.

There are 2 different directories called Program Files.... This is the second of these two directories, so it caries with it the first 6 characters a ~ and then 2.

sorry, must have taken more than 4 minutes for me to write...

Tanks to you 2 for the clarification. It brings me almost back to the vacuum tube legacy.

I'm pretty sure the basis of the problem is due to a bug in the script language execution. Namely, any left paren within a literal string (within quotes) will cause the error you saw. Doesn't matter if there is a matching right paren or not. Basically, the fix you used you used worked because it eliminated the left paren. Right parens don't seem to cause a problem. I logged this bug 5 months ago: https://synthiam.com/Community/Questions/8278

Another bug like that is the combination of a backslash directly followed by a quote slash ("). I logged it near the same time. https://synthiam.com/Community/Questions/8172&page=1

That thread discusses some work-arounds. Another work-around I have used since is this:

$ProgFilePath   ="C:\Program Files\TextScrubber\" # Wrong, will crash script.

  #So put a character between backslash and quote char.
$ProgFilePath   ="C:\Program Files\TextScrubber\|" 
$StrProgLen =Length($ProgFilePath) 

  # Now extract $ProgFilePath string up to and including the backslash
  # using $StrProgLen and add file name (variable or literal) 
$ScrubProg     =SubString($ProgFilePath,0,$StrProgLen)+$_ScrubProgName+".exe"
$ScrubInitFile =SubString($ProgFilePath,0,$StrProgLen)+$_ScrubProgName+".ini"
$ScrubEdit     =SubString($ProgFilePath,0,$StrProgLen)+$_ScrubEditName+".exe"
   # etc.

# You can see  the program crash by taking away the pound sign from 
# either of the next lines in this script.
#  $Test ="AAA(BBB"          
#  $Test ="AAA\"         

It was these problems which caused me to write the text scrub program in the first place as a means to overcome both bugs in text incoming from an external source. However, when trying to work-around the bugs from text generated within a script, it becomes complicated, but not impossible to get around.

Something like fixing up a string with a left paren bug might be amenable to an on-the-fly solution like for the backslash-quote bug but I haven't played with that theory as yet. Fortunately, in this case there was an alternative.

@WBS0001:

That can be a stopper and very annoying when working with strings, it's seems a problem in the parser, must be a priority.

After 5 months are those bugs still open ? Are you sure ?

@ptp. Well, clearly they haven't been fixed, so I can only surmise they are still open. They may be a lot harder to correct than it might appear and so have been on the back burner in favor of other things. Only the (groundhog's) shadow knows. With luck, it will only be six more weeks until they spring forth in all their updated glory.