For those that missed it, I'm still looking for feedback how to treat "00" when rounding. See my
original post. Right now, it formats according to the present float format float format - see
SetFormat for details.
Another problem with hex mode.
Because in hex mode, "a-f" are now "digits", this can invite some problems. From my testing, the problem ONLY occurs if these events "conspire"
As a note, the trailing "d" will treat the inputted size (if in bytes), as "decimal bytes" - e.g. 1 KB = 1000 bytes (the default behavior is to treat them as "binary bytes" - e.g. 1 KB = 1024 bytes). A trailing "b" would also cause the problem. The trailing "b" would treat the inputted value as a binary size (versus a decimal size). If the input is in bytes, it is interpretted as "binary bytes" by default.
1a) The size is stored in a variable (in hex format)
Code:
SetFormat, IntegerFast, hex
size := 5
;outputs 0x5
MsgBox, % size
;the trailing "d" is misinterpreted as part of the digit - "0x5d"
MsgBox, % autoByteFormat(size "d")
1b) The size is part of the parameter, in hex mode (why would do this) - "0x5d"
Code:
MsgBox, % autoByteFormat(0x5 "d")
Even if in hex mode, if the size is passed in decimal notation, there is no problem (since AHK doesn't convert the value to hex).
Code:
SetFormat, IntegerFast, hex
;in this case, the input is "5b", so it's not seen as hex - no "0x" prefix
MsgBox, % autoByteFormat(5 "b")
Surrounding the value in double quotes will prevent the problem - since AHK doesn't convert the value. Of course, if you enter the value is hex format - it's your own stupidity
However, this only works if you don't later use the value in an math operation. If you stored the byte size (as an integer), and did math to it, then it would be converted after the operation - so, the problem will still exist.
Code:
SetFormat, IntegerFast, hex
size := "5"
;outputs "5"
MsgBox, % size
;doubled the size
size *= 2
;outputs "0xa"
MsgBox, % size
;the trailing "d" is misinterpreted as part of the digit - "0xad"
MsgBox, % autoByteFormat(size "d")
So, at this point there are two options.
1) Assume the value will never be in hex form. This, in my opinion might not be the best option.
For example,
autoByteFormat can work directly with the return from a call to the
FileGetSize command - provided the return is in bytes (which is the default).
If you are in hex mode, the return for the
FileGetSize command is in hex format. Therefore, to allow this scenario, I would recommend the second option.
2) Specify a "separator" that MUST be used before the trailing "b", or "d" (if specified). I was thinking a ":", but I'm open to suggestions. If the trailing "i" is used, there will be no need for it (since "i" is not a valid hex digit), so it will be optional. It will still be allowed - for consistency.
Note: this separator will only be required if the size is in hex format. If in decimal, the separator will be optional - for consistency.
So, this call would look like this.
Code:
;example using FileGetSize
SetFormat, IntegerFast, hex
FileGetSize, FileSize, someFile.txt
;the trailing "d" wouldn't be misinterpreted as a hex digit
MsgBox, % autoByteFormat(FileSize ":d")
The other scenario that introduces problems is when using "EB" or "EiB" as the units -
exabytes and
exbibytes, respectively. However, this only occurs if "merging" a size and unit. If the size and unit are together (like most cases), and you specify the size in decimal units (which you should), then there will be no need for the ":", but it will be allowed - for consistency.
Code:
;example by "merging" size and unit
;possible scenarios include a GUI converter which has a drop down for sizes, units, etc - e.g. a GUI that makes use of this function.
SetFormat, IntegerFast, hex
size := 5
unit := "eb"
;separates the size and unit
separator := ""
;trailing is blank, so the value is interpreted based on unit
;(decimal for decimal units, and binary for binary units)
trailing := ""
;outputs 0x5eb (the "eb" is misinterpreted as part of the number)
MsgBox, % size . unit
;the "eb" wouldn't be misinterpreted as hex digits
MsgBox, % autoByteFormat(size . separator ":" unit . trailing, "D,")
Note, the above format is a "universal" format. It will work in all cases: if size is in hex or decimal, for any unit, and for any "trailing" (either "b", "i", "d", or none (blank)). The usage for the "trailing" will be described (in detail) on the webpage.
So, I'm thinking that this option is best. The downside is if a ":" was meant to be used as the separator between the size and unit, there would need to be two of them. If only one was used, it wouldn't be seen as the separator (when "parsing" the input for the settings, such as the separator). Note: the actual result (the size) would be the same regardless, but the default separator wouldn't be.
However, if you follow the above "template", then <separator> would equal ":", and there would be no problem.
Code:
;Some examples (and their output)
;outputs 5,000,000.00TB
MsgBox, % autoByteFormat("5:eb", "D,")
;outputs 5,000,000.00TB
MsgBox, % autoByteFormat("5eb", "D,")
;outputs 5,000,000.00:TB
MsgBox, % autoByteFormat("5::eb", "D,")
;outputs 5,000,000.00 TB
MsgBox, % autoByteFormat("5 :eb", "D,")
;outputs 5,000,000.00: TB
MsgBox, % autoByteFormat("5: eb", "D,")
;outputs 5,000,000.00: TB
MsgBox, % autoByteFormat("5: :eb", "D,")
Login
Register
FAQ
Search
OK, I feel better with that off my chest.