The issue is with the (x86) in the command. I built a link and call that link instead of the direct exe. The link would point to the exe. The link is stored in a directory that is simple like "C:\DirectoryWithoutSpacesOrSpecialCharacters".

just a work around and someone else may have a solution.

can you try the following:

1)

Exec("""C:\Program Files (x86)\RoboRealm\RoboRealm.exe""") 

or

2)

Exec("\"C:\Program Files (x86)\RoboRealm\RoboRealm.exe\"")

I have tried using escape characters and haven't gotten it to work. I dont know that I tried those sequences though.

is a guess,

it will depend first how the EZB engine parses and handle escape characters (if it supports)

secondly it depends how the shell command is executed, i'm guessing the string is being passed directly to the shell versus a detailed call (working directory, program path, arguments)

try this:

Exec("C:\progra~2\RoboRealm\RoboRealm.exe") 

basically you replaced the long name with a DOS (yes before windows) path name (8 characters):

to obtain DOS PATHs run:

dir /x

in the parent directory for each sub-directory.

cheers

The last command did work.

Exec("C:\progra~2\RoboRealm\RoboRealm.exe")

Tanks to you both

Glad you got it working. I think you can also call the roborealm file directly if you are using multiple of them. It has been so long since I did this but it is either possible to call the robo file directly or pass it in as a parameter. I cant remember which.

did both options generated errors in EZB ?

I had faith that the first option could work too..

@ 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.

Haha - it's been actively worked on. Hasn't been a largely reported issue, outside of the few users in the other thread - with a workaround for the time being. We have a significant software update for v4.x/2 in March which has a quicker parser that resolves this issue.