Community Question

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

generates an error : missing ")" in expression.

I suppose the (x86) within the command generate the problem.

Any suggestion to work around this problem?


User-inserted image
Aerius
Commented February 2016
Tanks to you 2 for the clarification.
It brings me almost back to the vacuum tube legacy.
WBS00001
Commented February 2016
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:
http://www.ez-robot.com/Community/Forum/Thread?threadId=8278

Another bug like that is the combination of a backslash directly followed by a quote slash (\").
I logged it near the same time.
http://www.ez-robot.com/Community/Forum/Thread?threadId=8172&page=1

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

Code:


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

ptp
Commented February 2016
@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 ?
WBS00001
Commented February 2016
@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.
DJ Sures
Commented February 2016
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.
Question
AvatarAerius
Asked on Tuesday, February 2, 2016