Scripting and CRLF...

[jacky]

Well, this one bugged me for a while yesterday. There seems to be a bit of a bug in the way XY handles CRLF in scripting. It's almost as if it looks for the actual string "<br>" and not an actual CRLF (0D0A) or something...

Here, see the problem :

Code: Select all

 set $m,"foo<br>bar";
 strpos $p,$m,"<br>";
 msg $p;
 // shows 3, as expected

 copytext "foo<br>bar";
 set $m,<clipboard>;
 strpos $p,$m,"<br>";
 msg $p;
 // shows -1 (not found) !!

So last night I was getting a list of filenames from XY's To Clipboard feature, and I needed to make sure every line ends with a CRLF, ie. when there's only one item XY doesn't put one so I wanted to add one, but only then and not if there's already one.
Problem is, XY tells me there are no CRLF all the time, even when there are, unless I don't search for "<br>" but copy it to the clipboard and search for the clipboard, a pretty unexpected thing...

Here's another one I think is wrong :

Code: Select all

 br "<br>";
 set $m,"foo<br>bar";
 msg $m;
 br "CRLF";
 msg $m;

Shouldn't both msg show the same thing, as they show the same variable which was set before changing the line break ?

After all, this shows the same thing :

Code: Select all

 copytext "FOO";
 set $m,"foo<clipboard>bar";
 msg $m;
 copytext "BAR";
 msg $m;

"fooFOObar" even the second time, not "fooBARbar"! Same goes for other variables, so why not <br> ?

[admin]

There are three commands that will convert the current line-breaker (default <br>) to CRLF if it is found in their first argument ("text"): copytext, msg, text.

[jacky]

There are three commands that will convert the current line-breaker (default <br>) to CRLF if it is found in their first argument ("text"): copytext, msg, text.

Yeah, ok, so... is there a reason for that ?? Because that doesn't seem very logical to me, in fact quite the opposite, it looks very unexpected to me

This is a unique behavior for this special variable, and I don't see why. And it means if one uses msg commands to debug something that doesn't work, good luck understanding anything given that behavior, and one cannot, say, locate a CRLF in a string unless having to do a copytext "<br>"; set $br, <clipboard>; to by-pass the "limitations" of variable <br>

[admin]

There are three commands that will convert the current line-breaker (default <br>) to CRLF if it is found in their first argument ("text"): copytext, msg, text.

Yeah, ok, so... is there a reason for that ?? Because that doesn't seem very logical to me, in fact quite the opposite, it looks very unexpected to me

This is a unique behavior for this special variable, and I don't see why. And it means if one uses msg commands to debug something that doesn't work, good luck understanding anything given that behavior, and one cannot, say, locate a CRLF in a string unless having to do a copytext "<br>"; set $br, <clipboard>; to by-pass the "limitations" of variable <br>

I could offer some predefined constants like $CRLF...

[jacky]

I could offer some predefined constants like $CRLF...

I'd say probably more <crlf> to keep things consistent, but yes that'd be good. Although I have to ask, why just not treat <br> (or whatever is set using br) as any other variables, instead of restricting it to only 3 commands ? Wouldn't that be easier ?

[admin]

I could offer some predefined constants like $CRLF...

I'd say probably more <crlf> to keep things consistent, but yes that'd be good. Although I have to ask, why just not treat <br> (or whatever is set using br) as any other variables, instead of restricting it to only 3 commands ? Wouldn't that be easier ?

Okay, now I see what you mean (distracted by soccer...) ... yeah, why not? Good question...

[admin]

I could offer some predefined constants like $CRLF...

I'd say probably more <crlf> to keep things consistent, but yes that'd be good. Although I have to ask, why just not treat <br> (or whatever is set using br) as any other variables, instead of restricting it to only 3 commands ? Wouldn't that be easier ?

Okay, now I see what you mean (distracted by soccer...) ... yeah, why not? Good question...

Ok, the line breaker is not your typical XY variable, because it is resolved depedning on the context! In msg command it is resolved to LF, in copytext and text it is resolved to CRLF.

So, I'd better add <CRLF> as a fixed and predictable way to enter a CRLF.

[jacky]

Ok, the line breaker is not your typical XY variable, because it is resolved depedning on the context! In msg command it is resolved to LF, in copytext and text it is resolved to CRLF.

So, I'd better add <CRLF> as a fixed and predictable way to enter a CRLF.

Yeah, a <crlf> would be quite useful then I think.

Question though, cause I'm curious: why for msg is it a LF only ?? Cause CRLF seems to work just as well, at least when I do this it looks like it:

Code: Select all

 copytext "<br>";
 msg "one<br>two<clipboard>three";

[admin]

Ok, the line breaker is not your typical XY variable, because it is resolved depedning on the context! In msg command it is resolved to LF, in copytext and text it is resolved to CRLF.

So, I'd better add <CRLF> as a fixed and predictable way to enter a CRLF.

Yeah, a <crlf> would be quite useful then I think.

Question though, cause I'm curious: why for msg is it a LF only ?? Cause CRLF seems to work just as well, at least when I do this it looks like it:

Code: Select all

 copytext "<br>";
 msg "one<br>two<clipboard>three";

When you do Ctrl+C to copy the message box, you'll see the difference: CRLF will produce questions marks...

[jacky]

When you do Ctrl+C to copy the message box, you'll see the difference: CRLF will produce questions marks...

hmm ok. No question marks here, though I do see a difference, yes:

Code: Select all

---------------------------
XYplorer
---------------------------
one
two

three
---------------------------
OK   
---------------------------

[admin]

When you do Ctrl+C to copy the message box, you'll see the difference: CRLF will produce questions marks...

hmm ok. No question marks here, though I do see a difference, yes:

Code: Select all

---------------------------
XYplorer
---------------------------
one
two

three
---------------------------
OK   
---------------------------

Ah, I see now. The question mark is an artifact of UltraEdit when trying to resolve bytes "0D 0D 0A". When I paste it into this post I get the same as you.