This is tricky apparently, because your input string may not really be what you think it is due to JScript doing some pre-escaping itself.
You might believe your are processing c:\path\to\file.csv when really (and hopefully) you are processing this instead: c:\\path\\to\\file.csv
How is the path being passed in, I mean, from what? The FileSystemWatcher?
Because “magically” this works …
function doslashes()
{
var str = 'D:\\pathname\\Zilename.csv';
newstr = str.replace(/\\/g,"/");
return 'in: '+str + "\r\nout: " + newstr;
}
If you run the FSW in Debug, you can see that the path is already escaped (the FSW class does this I believe), so what is really coming into your JScript is probably literally c:\\path\\to\\file.csv
Scary… here is the start of what appearz to work… need to replace every “special” escape sequence …
So in this example, \p is not special, but \t and \f are special sequences. We did “ok” so far, but because \p is not “special” it is interpreted simply as p, and so the replacement with / does not occur.
Simplest method would be to replace the entire alphabet !!!
Well I “sort of glad” you labelled it tricky as well as I was well and truly over it! I saw some long regEx strings to cover a whole heap of characters. I going to just use the [:Filename] part and pass that in with a {SETTING:x} for location so I do not need to deal with a '' again!
I was beating on this issue for a few hours yesterday, and I still cannot figure out a good working solution.
I think the problem with detection is that escaped characters, when special, are multi-byte. But an escaped regular character (non-special) are not. For example, the length of this string, according to JS is 16 … but it should be 19
Every instance of a backslash is not counted and does not make up part of the string length. It is a difficult problem to solve.
I think the solution probably involves converting the string into byte form. I was playing around with the encodeURI() function which is able to detect escaped special characters, but it does not detect escaped non-special characters.
C%3Apath%09o%0Cile.csv
||| ||| |||
: \t \f
The thing is, it misses is \p because it is not special. I do think that is the “right approach”, but we need a different conversion.
JS ECMA6 has String.raw which I think might work, but alas, we are working with ECMA3 I believe.
P.S. I wold like to figure out a good working solution, but in the meantime, there is a very simple workaround to the problem as it pertains to your implementation:
Do not use backslashes in your File Monitor Path. Use Forward slashes.
I appreciate you spending time on this but please do not spend anymore I was a bit like you thinking surely it cannot be that hard? <- Understatement.
So I am going to just create a {SETTING:x} that will hold the PATH as a D:\\PATH\\ or as D:/PATH/ and then I will just append to [:Filename] which is outputted from File Monitor. Would like to use just 1 so need to find the compatible specification for both File Monitor and JScript.
PS: Of course I have not studied the code but there may be a possibility that the DLL (FM) could be changed to return file spec in '/' or '\\' but in any case best practises would require a configurable Directory Path so point is moot.
I was thinking the same thing, but then I thought to myself “how hard could it possibly be to get proper output from JScript?”.
Well, I implemented the library above and I still cannot get it to work… not sure why. But I cannot figure out how to “uncheck” the last option on that webpage in the code, and that is the important option to “turn off” to make it work as seen in the screenshot (“treat as JavaScript string body” option needs to be “off”).
In any case, because of the inherent “issues” with backslashes being an escape character, I would recommend you don’t use them in paths at all; instead use the forward slash /everywhere. Nothing will break AFAIK, and you won’t need to deal with this “issue” ever again.
I remember when putting together the Browser Printer Customer Display, I was fighting a similar problem when trying to display images for the Order Items via the Printer Template. In the end, I flipped all the slashes to / and all the problems were gone. No workarounds necessary.
Windows and Programs understand the forward slash anyway …
Ok @QMcKay I had to come back here because I cannot use {SETTING:x} as a Path Spec in File Monitor as I wanted to just pass the correct usage of “/” to both File Monitor & JScript
But I have a Solution!
Apply as a Path specification "D:/SomePath/" in File Monitor which will return:
Then in your JScript you can use something like:
var fContent = file.ReadFromFile(location.substr(0,location.lastIndexOf("/")+1)+datafile);
I was a bit like you thinking surely it cannot be that hard? <- Understatement.
