Programmable column

Discussion & Support for xplorer² professional

Moderators: fgagnon, nikos, Site Mods

Post Reply
sanferno
Silver Member
Silver Member
Posts: 288
Joined: 2013 Nov 30, 18:40

Programmable column

Post by sanferno »

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... :roll:
User avatar
nikos
Site Admin
Site Admin
Posts: 15794
Joined: 2002 Feb 07, 15:57
Location: UK
Contact:

Re: Programmable column

Post by nikos »

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
sanferno
Silver Member
Silver Member
Posts: 288
Joined: 2013 Nov 30, 18:40

Re: Programmable column

Post by sanferno »

nikos wrote: 2018 Jun 10, 17:41 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.
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. :oops:

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. :wink:
User avatar
nikos
Site Admin
Site Admin
Posts: 15794
Joined: 2002 Feb 07, 15:57
Location: UK
Contact:

Re: Programmable column

Post by nikos »

I fudged the bug but keep in mind that as xplorer2 doesn't support floating point properties, you won't get accurate calculations anyway
sanferno
Silver Member
Silver Member
Posts: 288
Joined: 2013 Nov 30, 18:40

Re: Programmable column

Post by sanferno »

Ok, nice to know. Anyway, at least it served for correcting that bug :beer:
EMathews3
Bronze Member
Bronze Member
Posts: 87
Joined: 2014 Aug 23, 12:54

Re: Programmable column: Division or lookalike

Post by EMathews3 »

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:

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}
)
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:

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}
)
The error message is "Syntax error: wrong function argument", with the formula re-rendered as

Code: Select all

if(${Size}>999,mid(str(${Size}),1,len(str(${Size}))-2),${Size})
and the second 'len' highlighted/selected. Wha? Experimenting shows that this

Code: Select all

len( str( ${Size} ) ) - 0
gives correct-looking results; same with subtracting 1 or 2 instead of 0.
User avatar
nikos
Site Admin
Site Admin
Posts: 15794
Joined: 2002 Feb 07, 15:57
Location: UK
Contact:

Re: Programmable column

Post by nikos »

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!
EMathews3
Bronze Member
Bronze Member
Posts: 87
Joined: 2014 Aug 23, 12:54

Re: Programmable column

Post by EMathews3 »

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).
User avatar
nikos
Site Admin
Site Admin
Posts: 15794
Joined: 2002 Feb 07, 15:57
Location: UK
Contact:

Re: Programmable column

Post by nikos »

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!
EMathews3
Bronze Member
Bronze Member
Posts: 87
Joined: 2014 Aug 23, 12:54

Re: Programmable column

Post by EMathews3 »

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 :(
User avatar
nikos
Site Admin
Site Admin
Posts: 15794
Joined: 2002 Feb 07, 15:57
Location: UK
Contact:

Re: Programmable column

Post by nikos »

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?
EMathews3
Bronze Member
Bronze Member
Posts: 87
Joined: 2014 Aug 23, 12:54

Re: Programmable column

Post by EMathews3 »

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.
EMathews3
Bronze Member
Bronze Member
Posts: 87
Joined: 2014 Aug 23, 12:54

Re: Programmable column

Post by EMathews3 »

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?
User avatar
nikos
Site Admin
Site Admin
Posts: 15794
Joined: 2002 Feb 07, 15:57
Location: UK
Contact:

Re: Programmable column

Post by nikos »

this underscore represents a newline (CR)
newlines cannot show in a single line so they are replaced
EMathews3
Bronze Member
Bronze Member
Posts: 87
Joined: 2014 Aug 23, 12:54

Re: Programmable column

Post by EMathews3 »

Yep I see how the multi-line output from Dir is wrapped onto one line like

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_
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.
Post Reply