Programmable column
Moderators: fgagnon, nikos, Site Mods
Programmable column
Hi,
I'm trying to making use of Programmable Column, but I'm doing something wrong. I want to know how much will cost me each file stored in Azure using a scrap window (result of searching for files older than one month).
Here are the parameters:
Size in bytes of the file = 104857600
Bytes per GB: 1073741824
Euros per GB = 0.0085
So the programmable column expressions should be, isn't it?: ( ${Size} * 0.0085 ) / 1073741824
As I understand, the result should be the pricing, but I don't get anything...
I'm trying to making use of Programmable Column, but I'm doing something wrong. I want to know how much will cost me each file stored in Azure using a scrap window (result of searching for files older than one month).
Here are the parameters:
Size in bytes of the file = 104857600
Bytes per GB: 1073741824
Euros per GB = 0.0085
So the programmable column expressions should be, isn't it?: ( ${Size} * 0.0085 ) / 1073741824
As I understand, the result should be the pricing, but I don't get anything...
Re: Programmable column
this is inspired use but why do it on a file by file basis? Calculate the sum total of bytes and you have the euro price.
as for why doesn't it work, I am looking into it, there may be a bug with division
as for why doesn't it work, I am looking into it, there may be a bug with division
Re: Programmable column
I was just checking old files, and thought in this new programmable column. Tried to get the pricing as I told you, but got stuck with that situation.
As for division, yes, it seems to be failing (for intance: 4/2 = 4?).
Is not an urgen issue for me, so you can take your time.
Re: Programmable column
I fudged the bug but keep in mind that as xplorer2 doesn't support floating point properties, you won't get accurate calculations anyway
Re: Programmable column
Ok, nice to know. Anyway, at least it served for correcting that bug
Re: Programmable column: Division or lookalike
How is this supposed to work? Using licensed 4.0.0.2 ULT x64 2018-05-21.
The goal: for certain log files, display the number of log entries in the file. For other files, display blank or Size [S] - don't really care. Assume the relevant log files are 1,000 bytes or larger, with sizes in multiples of 100. Each log entry is 100 bytes long (99 bytes of visible data plus line-terminator). As a result, the file size is always [number of lines] multiplied by 100.
Ideally, the formula would be ${Size} / 100, but that did not work. As a workaround, try: convert ${Size} to a string, and drop the trailing two zeros. Go ahead and skip files whose size-strings are shorter than four digits (the thousands separator does not exist in this problem domain).
So this works:
The relevant files appear as one-tenth their size. We want them to appear as one one-hundredth of their size, so, drop one more zero, but this fails:
The error message is "Syntax error: wrong function argument", with the formula re-rendered as
and the second 'len' highlighted/selected. Wha? Experimenting shows that this gives correct-looking results; same with subtracting 1 or 2 instead of 0.
The goal: for certain log files, display the number of log entries in the file. For other files, display blank or Size [S] - don't really care. Assume the relevant log files are 1,000 bytes or larger, with sizes in multiples of 100. Each log entry is 100 bytes long (99 bytes of visible data plus line-terminator). As a result, the file size is always [number of lines] multiplied by 100.
Ideally, the formula would be ${Size} / 100, but that did not work. As a workaround, try: convert ${Size} to a string, and drop the trailing two zeros. Go ahead and skip files whose size-strings are shorter than four digits (the thousands separator does not exist in this problem domain).
So this works:
Code: Select all
# for file sizes > 999 bytes, convert Size to a string and return substring: from the first character, to the end, except for the last-one character.
# for file sizes <= 999 bytes, return the actual Size
if ( ${Size} > 999
,mid( str( ${Size} ), 1, len( str( ${Size} ) ) - 1 )
, ${Size}
)
Code: Select all
# for file sizes > 999 bytes, convert Size to a string and return substring: from the first character, to the end, except for the last-*two* characters.
# for file sizes <= 999 bytes, return the actual Size
if ( ${Size} > 999
,mid( str( ${Size} ), 1, len( str( ${Size} ) ) - 2 )
, ${Size}
)
Code: Select all
if(${Size}>999,mid(str(${Size}),1,len(str(${Size}))-2),${Size})
Code: Select all
len( str( ${Size} ) ) - 0
Re: Programmable column
there is a bug with division, which I have fixed already. There will be a beta version released soon so you can check how this works for you then!
Re: Programmable column
Yes, I already knew about the division bug and the pending fix.
This problem report is supposed to be about the Mid(Str, Pos, Len - 1) versus Mid(Str, Pos, Len - 2).
This problem report is supposed to be about the Mid(Str, Pos, Len - 1) versus Mid(Str, Pos, Len - 2).
Re: Programmable column
this works for me but probably it is because the soon-to-be-released beta version has relaxed the syntax errors during the testing phase. More on that soon!
Re: Programmable column
Please make the Programmable Column leave the uppercase/lowercase alone!
My program to populate the column produces output that is cased a certain way, but the Column throws that away
My program to populate the column produces output that is cased a certain way, but the Column throws that away
Re: Programmable column
this isn't as simple as it sounds, but I will see what can be done for a future version
why is case so important for your programmable column?
why is case so important for your programmable column?
Re: Programmable column
The 'plugin' returns six to seven data items, the most important of which are six to nine characters long. The casing helps the user with reading the information; spacing between items also helps. The important items are standard international terms, so they need to appear in the form that people expect - as in, following the standard.
Re: Programmable column
Recently upgraded to 4.2.0.0 ULT x64 2019-03-01. But now the programmable column's System call seems to be appending a "_" underscore to its output. Change System to execute a simple Echo command and the _ stays. Remove the System call and the _ is gone. Is this a regression?
Re: Programmable column
this underscore represents a newline (CR)
newlines cannot show in a single line so they are replaced
newlines cannot show in a single line so they are replaced
Re: Programmable column
Yep I see how the multi-line output from Dir is wrapped onto one line like
Here's a suggestion: please drop the last newline if it is the last piece of the output.
The programmable column needs to be able to call any program that produces console / standard output, and those print complete lines, which include trailing newlines. Most utilities will not be able to change just to not-print a last newline for special handling, like converting newlines to underscores. The sensible solution is to not-be a special case - as much as possible. I can see not-throwing away all lines after the first, but I cannot see turning an invisible character into a visible character when such is not needed.
Code: Select all
volume in drive c is win_ volume serial number is 12ab-12ab__ directory of c:\src\lazarus__2019-02-04 05:41 pm test.png_ 1 file(s) 565 bytes_ 0 dir(s) 8,772,736 bytes free_
The programmable column needs to be able to call any program that produces console / standard output, and those print complete lines, which include trailing newlines. Most utilities will not be able to change just to not-print a last newline for special handling, like converting newlines to underscores. The sensible solution is to not-be a special case - as much as possible. I can see not-throwing away all lines after the first, but I cannot see turning an invisible character into a visible character when such is not needed.