AutoHotkey Community

[Dippy46]

@Skan,

The inabilty to read and write binary files is unfortunately a problem we all have to suffer, so its better to understand why we can't. As PhiLho says AHK cannot possible read binary files per se. This is not a limitation of AHK but the fundamental design of all string handling , the dreaded NULL terminator.

Back in the early days of MSBasic (when Bill was just another kid on the block), things were handled differently. Now let's recap

memory max 65535 just 2 bytes to hold segment + offset of string pointer
string max 256 just 1 byte to hold the length. Later 65535
That arrangement allowed one to make a string that contained all 256 bytes. You could manipulate string pointers using varptr, and bytes could be read using asc$ and written using chr$. So of course it begs the question: what nut introduced the NULL terminator. And no I don't know.

Below shows proof of concept that AHK DOES in fact handle binary files and strings just as well as text. Of course the subtlety here is we've made sure it doesn't contain any NULL's ie chr(0).

[Laszlo]

These limitations are well documented in the Help, and solutions for reading and writing binary files (based on dll calls) were already posted a year and a half ago. There you can read: "The binary file I/O functions store/load the data to/from AHK variables, which may contain NULL characters, therefore, they must not be manipulated as ordinary strings. Not even assignments or StrLen is allowed. If these variables are used as function parameters, they must be defined as ByRef, otherwise the strings get truncated at the first NULL".

[Laszlo]

You have to distinguish STRINGS form other (binary) data. Strings were introduced to handle text, mostly I/O messages. Texts do not contain certain characters, so it is natural to pick one as a delimiter. If you use strings for storing other data, you are in the state of sin.

There is no problem with NUL delimited strings, but only with their misuse. AHK is a string based language, where everything is a string: text, numbers, ID's, addresses, etc. Therefore, AHK cannot handle binary data in its native form. Several posts provided solutions (started almost two years ago) by coding binary data into strings of allowed characters: hex digits, base64, base85 or pebwa (invented by PhiLho).

[Dippy46]

@Laszlo,

Oh yes Sir, I'm fully aware of all the references, possibly ad nauseum. The fact however is, that whilst we tell people that it's not possible, I thought it might be useful to people that don't have our knowledge, as to why it doesn't work. It also serves as a challenge, because anyone with the correct knowledge and determination, could quite easily write an add-on library that would provide all the necessary functionality.


Regards

Dave.
_________________
Simple ideas lie within reach, only of complex minds

[PhiLho]

[SKAN]

[Laszlo]

[PhiLho]

[Chris]

[PhiLho]

I understand that Laszlo would prefer a generic solution, but in 90 to 99% of function uses, a Return by copy is OK, as most return values are small.
So if doing optimization is made at the risk of breaking something (recursion for example), I would prefer a special Return to operate on large values, ie. programmer will need to tell AHK: "This data is special, treat it in a special way".
If Chris can make it generic, well that's better, of course.
_________________
vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

[SKAN]

[AngieX]

I like how I am incorporated into the GUI I feel famous

Great looking code. May I ask, how this could be tweaked to do two things:

1) Have a var_input = %, so the 50% is flexible

2) To turn this into a callable function, so the display is updated when the function is called. I envision something like UpdateGraph(var_width, var_height, var_start_color, var_end_color, var_input). I don't know how piped in variables/functions perciely work under AHK (I can think JavaScript . This is really giving me quick-ramp up to its protocols so I apprecaite your descriptions so much. So I would envision this to be called like UpdateGraph(250,250,0208FF,FFFFFF,50%) <- I know that is wrong all-together, but u get the idea I hope

That will make it real flexible, simple and modular. Hopefully you think that is right software protocol.

Thanks for advancing my original idea!

-AngieX%

[SKAN]

[AngieX]

I am trying to cram this all in my head, but do follow your logic soundly!

two questions -

What does 1 signify?
% CreateBMPGradient("bg.bmp","000000","FF0000",1) < what is 1?

Can this be further explored, the idea to have a % input - to basically have a BMP assignment, for 1%, 2% to 100%. Just 1-100 to keep it simple. Each one has a mathamatatial computation to some BMP configuration, then its pumped into BMP.

So, 16% would flow like:
% CreateBMPGradient("bg.bmp","16%","000000","FF0000",1)

I am way way over my head actually writing it out, but maybe if I can see some ways you write, I can follow the rythum for improving this object. I have some other ideas to make this more interesting, like a decay? -- so if a 16% was pumped in, then a 42% three seconds later, it will kick back up, but not in a fast skippy way. Kinda like a very nice car stereo equalizer.... so it look real smooth, remain live and programmable. Do you see where I am going with this? I think it will be fun to mess around with.

[SKAN]