Greetings.
I name all my project files the same way:
client_project_name_20190501_clw_v01.ext
My goal: select an existing file, duplicate it, give it today's date and update the version number in the file name.
Here are the macro and a screenshot. It works fine until I try to update the version number. What am I doing wrong?
And thanks!
Copy, update date and version of selected files.kmmacros (3.1 KB)
Replace these two Actions:
with this:
Search For:
clw_v(\d+)
Replace with:
clw_v%CalculateFormat%$1+1%00%
Thank you so much!
It works but I have a new problem. If I try on a file with today's date, I get an error: Action Failed - File action failed because destination already exists. Is there some sort of if then I need to use?
Copy, update date and version of selected files.kmmacros (3.9 KB)
Any thoughts on how I can fix this one?
The issue is NOT the date, but the KM Search and Replace action does NOT support use of RegEx Capture Fields ($1) in the Calculate or CalculateFormat token.
@peternlewis: Seems like a problem here. The Action just returns the wrong result, when, IMO, it should have thrown an error.
IAC, the workaround is easy. Just do the new version calculation outside of the Sarch and Replace action, like this:
#### DOWNLOAD:
<a class="attachment" href="/uploads/default/original/3X/e/e/eeff5d90492443f756897f2a8e518e035a411f21.kmmacros">Update Version # in File Name [Example].kmmacros</a> (3.6 KB)
**Note: This Macro was uploaded in a DISABLED state. You must enable before it can be triggered.**
---
---
Please try this approach in your Macro and let us know if it works for you.This is true, but it does support regex capture fields if you use the CALCULATE() function within the tokens, like so:
clw_v%CalculateFormat%CALCULATE($1+1)%00%
Copy, update date and version of selected files.kmmacros (3.9 KB)
Perhaps so, but where you are using the CALCULATE funciton is in fact a numeric calculation field, and so the CALCULATE funciton should not be required.
IAC, the Calculate and CalculateFormat tokens should throw an error instead of return the wrong answer.
Tokens cannot fail - there is no mechanism for tokens failing. So when the CalculateFormat token gets something it does not understand it returns nothing. Since it returns nothing, the file names match.
$1 does not work in calculations, only text fields, but on the bright side, this works:
clw_v%CalculateFormat%CALCULATE($1)+1%00%
(at least it works in my version, I'm not sure about 8.x - I have improved a bunch of stuff related to regex processing in the 9.x development version).
This corrected macro works like a charm! Thank you guys so very much! I really appreciate your time and commitment to this app.
I hope that includes proper handling of RegEx Capture Groups in Tokens.
That is not my experience. In this case, the Token just ignores the "$", and returns the calculation of 1 + 2. This is NOT the same a returning "nothing".
Show this:
If have no idea what you mean by "Tokens cannot fail', because they obviously can and do.
Perhaps you mean you have not provided for any error trapping in your implementation of tokens.
Regardless of the name, a token is really no different from a function -- it just uses different syntax. I've never understood why KM has functions and tokens (which is an uncommon syntax element). Why not just have functions?
No - it is a numeric calculation field, which is exactly why you need to use the CALCULATE function. Because $1 is available in text fields, not numeric fields.
You are correct, $1 is a valid calculation, it is not failing. $nn is a hex number (so $12 is 18 for example). So $1 is 1. See the Calculations user manual section.
Actually, as I have learned, $1 works in both the Calculate token and in the CALCULATE function. The KM Wiki Calculations article states that the "$" denotes a hex number. Both the token and function with use "$" as a hex indicator in some cases.
So, when "$1" is used in a Search and Replace action using RegEx, it would normally refer to the RegEx Capture Group 1. But KM interpretes it as a hex number instead:
So, Peter, your solution is to put the "$1" in a CALCULATE function, like this:
However, sometimes the CALCULATE function treats "$" as a hex number indicator, like here:
So Peter, I am still confused:
How does the CALCULATE function decide when to treat the "$" as a hex indicator, and when to treat it as a RegEx Capture Group?
BTW, I am just curious about the $ hex usage. I've never seen that association, and I'm just wondering why you included it in KM, when you already have the "0x" indicator?
OK, I will try to add some enlightenment.
In a numeric field, $n always means hex. So $12 evaluates as ā18ā.
In a text regex replacement field, $n means the matched text for that capture, if n is between 0 and the number of captures. If n is more than that, then$n means nothing and remains ā$nā (this may have changed for 9, but this is the correct behaviour)
In a text field otherwise, then $n means nothing remains ā$nā.
The %Calculate% token allows you to have numeric parts in a text field, and the CALCULATE function allows you to have text parts in a numeric field.
So:
*%Calculate%$1+2% will always return ā3ā.
%Calculate%CALCULATE($1)+2%, in a regex replacement field with at least one capture group, would replace the $1 with the capture result, and then pass that string to the calculation engine to evaluate, which would return a number as a string, and then that string would have ā+1ā appended to it, and then that would be evaluated by the calculation engine, resulting in a final number as a string.%Calculate%CALCULATE($1)+2%, in any other text field would pass $1 to the calculation ending, which will return ā1ā, and then pass 1+2 to the calculation engine, which will return ā3ā.The text processing engine decides based on wether this is a regex replacement field with the requisite number of capture groups (this latter may vary in 9, I'm not sure - if you expect ā$3ā to mean something different depending on whether your regex has 2 or 4 capture groups, then you have bigger problems.
It stems from my Pascal days, $x was the representation of a hex number. From Wikipedia:
Other assembly languages (6502, Motorola), Pascal, Delphi, some versions of BASIC (Commodore), GameMaker Language, Godot and Forth use $ as a prefix: $5A3.
OK, that makes perfect sense.
In that case, why not treat both the Calculate token the same as the Calculate function, and always evaluate any RegEx Capture Groups before you do anything else?
This will eliminate a lot of confusion, and ensure consistency while making it easier for all to use.