XYplorer Beta Club

Check your templates, maybe they start with "(2)"?

Yes, they start with " (2)", but it should be used only on collisions.

If only one item is copied, it doesn't use the template. Similarly, if two items are copied and an item with the name doesn't exist, only one should be copied with the template

i.e.; Bold is unexpected behavior

if Funky.txt does not exist in D:\Demo\Fun
CopyAs "Funky.txt", "D:\Demo\Fun", "D:\Demo\New.txt" --Copies as Funky.txt - Good
CopyAs "Funky.txt", "D:\Demo\Fun", "D:\Demo\New.txt|D:\Demo\Old.txt" --Copies as Funky (2).txt and Funky (3).txt -- Wrong --Should be copied as Funky.txt and Funky (2).txt

if Funky.txt already exists in D:\Demo\Fun
CopyAs "Funky.txt", "D:\Demo\Fun", "D:\Demo\New.txt" --Gives me a collision prompt - OK
CopyAs "Funky.txt", "D:\Demo\Fun", "D:\Demo\New.txt|D:\Demo\Old.txt" --Copies as Funky (2).txt and Funky (3).txt -- Good

This is by design. The resulting names are more consistent like this, and this is IMO preferable.

It gives a feeling that one file was deleted

1) Drag C into position 2. (Making it: A|C|B)
2) Select C and hit OK.
3) It echos B instead of C.

It should return token 2 from the re-ordered list not the original list - just like it does if do the same but use: I fully realize using style 16 without style 2 is rather stupid but still...

Yep, bug. Fix comes.

Not sure if it's a bug or not, but it's definitely undesired behaviour.

Description: when having a multi-line piece of text -- not word wrap -- copied to clipboard, in-line rename pastes the whole thing joining the parts together (good), but the following scripting command fails with an error (bad).

Well, it might be a desired behavior. It's questionable whether this special feature of inline rename should be extended to scripting. Whatever, this is certainly not a bug.

admin wrote:Well, it might be a desired behavior. It's questionable whether this special feature of inline rename should be extended to scripting. Whatever, this is certainly not a bug.

OK, it's not a bug. But in what situation could be the desired behaviour? If I copy a bunch of text to clipboard, I would expect that all of it is pasted wherever I designate. When needing to rename a bunch of files with different extensions to have the same base, the scripting command is very handy.

Ah, works already! Simply use flag 16: PS: Next beta will slightly improve the functionality of flag=16 so that it's 100% identical to pasting into the inline box.

admin wrote:Ah, works already! Simply use flag 16:

Yes, indeed

SC folderreport wrongly adds an CR/LF after the last entry when parameter separator is left empty.

Just compare the two flavors Cheers,
FH

For a pure list it might be helpful to terminate *all* lines by crlf?

While the separator-operand explicitly states that separator is *between* the items. (I don't use the word 'lines' here )

So it might work as designed?
(I still hate IBM for this expression )

Hi Peter,

all formalisms aside, a loop over the resulting list should, nope, must have the same number of iterations, no matter wether default separation is used or not.

FH

Maybe, if I didn't understand you wrong, you should just use separator <crlf>?

Again: I think it might have sense if both versions exist - and you con choose.
And then the version without sep are wrong for you

(To say: my interpretation )