I think file is a string including quotes, if it contains spaces. So left(file, 1) will be the quote character.
Adding @nofilenamequoting fixes that without having to check for the quotes explicitly.
Probably not worth worrying about, but a filename may also start with a space, in a pathological case. Trim can deal with that without much extra code:
I suspect there are some behind-the-scenes shenanigans with how different commands are flagged to use/require files/arguments, but will wait for Jon's opinion, as he knows much more about this than I.
This will move files into new folders. But it only works for the first selected file, the others are ignored:
@nodeselect
@nofilenamequoting
Copy MOVE HERE CREATEFOLDER={=UCase(Left(file, 1))=} WHENEXISTS=replace
Quotes aren't needed for a single character, but adding them helps, surprisingly:
@nodeselect
@nofilenamequoting
Copy MOVE HERE CREATEFOLDER="{=UCase(Left(file, 1))=}" WHENEXISTS=replace
However, if we use an evaluator-generated command instead of an insertion code, everything is fine again. All files will be moved into new folders. No quotes needed:
I did not look at Evaluator things yet, but used like this, do they really help to make things more easy?
I would go straight for the JScript solution in a case like this, it can be debugged step by step and outcome is a lot more predictable, no?
Combining the old button codes with the new evaluators, to me this seems to be stuff for the brave! o)
I can see why this looks tempting with the short syntax, but expressing things as short as possible is not necessarily a solution for more complex tinkering.
Assembly language is short as well, is it easier to understand than C#, C++, Java etc.? I'd say not really, but yes, you have to learn some more basic aspects of the language as always initialising some things first e.g., but then you are way more free in what you can do and what approach you take. Just my 2 cents of course! o)
What kind of file is this? o) Look's like I'm a "beta warrior" too! o)
From experience there are a lot of special cases with button codes and things, I don't really wanna hate on them or the new evaluator functionality, you can surely manage the different syntax at some point, but the challenges may be in the unexpected, like here.
I read some more on the evaluators, if they are quicker than using jscript for generating simple column values e.g., why not! Every language and syntax can be a tool, and there's always the right and the wrong tool for a job.
@Jon
When reading about Evaluators, I had the impression these are also used internally for handling GUI updates / conditions etc.? Is it some kind of functionality that already existed in some state and you decided to make it available to the user as well? Or is this a complete new invention for the user in v13?