What about, in your first code example, trying to add single quote on both sides of each slash:

       "F:"+'\'+"Images"+'\'

Assign it to a variable and then use the variable.

Ignore me. I see you tried that.

@MathProf Thanks for the suggestion, unfortunately that doesn't work either. I don't think the scripting language will accept single quotes at all, but I'm not positive of that. Also, the first slash is accepted fine as in:

$TheFilePath ="F:\Images"

This works fine. It's only the " combination that generates an error.

Might as well take the opportunity of this post to expound on work arounds. I'm using arrays to hold the file names and select one to work with as needed. One work around was to do something like this:

$TheFilePath ="F:\Images\A_"

Basically any letter or character combination after the last slash. Then add that to the file name, such as:

#On disk, the filemame would be "A_PictureName.jpg"
$FileName =PictureName.jpg  #Here it is just the basic name
$TheFilePath ="F:\Images\A_"
$FileToUse =$TheFilePath+$FileName

You add the A_ to the beginning of the file name (on the disk) for anything you are going to parametrically add to the basic file path in the script. You still use the file name without the A_ in the script itself (as shown above). Of course, it can be any character or any combination of characters, not just A_. Just so you don't end up with the " combination anywhere.

Another work around is to put the whole file path and file name in the variables holding the file names in the script. But it is wasteful, and. worse yet, upsets my sensibilities. Not to mention makes it harder to update should you want to change the directory where the files are stored. That especially becomes a problem if others are using your script or project. Defining a path variable makes it easy for another person to simply assign their own path to the variable and have it automatically be reflected throughout the script(s).

For now I'm using the first work around and renaming the files themselves with the letter-underscore combination. That way I don't have to change all the variable entries that are holding the file names in the script when this problem is resolved. But I will have to rename all the file names on the disk files back to what they were. In the script all I need to do is get rid of the A_ in the $TheFilePath variable definition. Just one line of code. Changing the file names on the disk isn't a difficult job either as I use a great program called Rename Master. You can make changes to file names in an entire directory at once with it. It's amazing what all it can do. Often saved me a lot of work.

WB, yes, renaming files pretty much sux. When it comes to the scripting language, I'm a newbie, and so am just guessing until I start playing with it. Does the language allow the definition of special characters by utilizing their hex representation? For example,

$slasher = &h92 or

$slasher = 0x92

This method works fine for me. Give this a try:

#test of opening a file path
$FileName = "\test.jpg"  #the file name
$FilePath = "C:\Pictures"  #the path
$FileToUse = $FilePath+$FileName

Exec( "C:\Program Files\Windows Live\Photo Gallery\WLXPhotoGallery.exe", $FileToUse)

If Justin's approach doesn't fit your needs, you could try the C# version

$slasher = "\x92"

Oh, yep, for sure, Justin's approach is right on.

@MathProf Thanks again for a good suggestion. In this case though, it just converts the expression into a number instead of a character. Being untyped variables in the script language, I can't readily coerce it into being a character. I tried using it directly in the path variable as well, but it just appended a number instead of a slash:

$TheFilePath ="F:\Images"+0x92
#Ends up with: F:\Images146

@JustinRatliff An excellent suggestion. One of those "Why didn't I think of that" kind. Just adds one extra character to the list of names. I think that's what I will do. Come to think of it, when it comes time to get rid of the slash in the stored names in the script, I can just use the search and replace editing function to get rid of them all in an instant. If the bug is never fixed, well ... at least that works and doesn't upset my sensibilities (as much).:) Thanks again.

I'm not sure I would call it a "bug" I view it as more of syntax peculiarity to which there are many you might find. I think it's because in the Script help, it always shows a complete path and file name, in my mind it was probably only intended for a file or .exe path to be listed rather than a break down to respect just a path directory. That's a guess of course.

@JustinRatliff You may be right, but it's been my experience that anything goes as long as it's between quotation marks. Keywords, operators, reserved words, whatever. So I still think this a bug. The script help does leave a lot to be desired, so not being in there isn't particularly meaningful. The only way to find out Script behavior on many issues is just to try it and see what happens. I've been doing that as I go. Adding to the help file for my own reference. But, what the heck, it can even be fun trying to find ways around the little buggy critters. Just another good mental exercise.

I totally agree experimenting and trying new things is the way to go. In some ways I look at what we do as helping push the limits of what the EZb/ARC can do and we all get to help each other along the way.

@JustinRatliff I waited a few days to see if there was going to be any official response to thie problem, but I guess not. Anyway, it's time to close it out and give credit where credit is due. Thanks so much for your suggestion, it filled the bill for a good work-around.

You are welcome @WBS00001, glad I could help.