David Heffernan

It doesn't much matter what the thing is that you encrypt. What matters is who encrypts it, and who has knowledge of the key or keys used to encrypt and decrypt. That's what I mean by usage. As for how you do it, convert the text to binary using a well defined encoding, e.g. UTF8, and encrypt that. Encryption algorithms work with binary data not text.

It depends on what your usage is

Pro has command line compiler

Answer found in the code which we can't see.

Save the file to a directory where you have write permission

Also, this isn't how to display binary in a hex editor.

Big lesson here is always to show a proper minimal but complete reproduction. It wasn't clear what the problem was from the first post which was descriptive. Code doesn't lie.

Should be #0 rather than '#0'. Your code is replacing the text '#0' which doesn't appear in the string.

Can you show what the output of your code is. It should be easy to produce a minimal complete program, a console app, that demonstrates the behaviour that you are struggling with.

But it's not text, you can't treat it as text, and there's nothing to learn. What you should learn is how text is encoded. Why not do that?

Both Matlab and R seem completely inappropriate for this usage scenario. But R is not graphical software. It's best thought of as a scripting language designed for statistical use.

You aren't going to be able to display the contents of a binary file in a rich edit control like this. If you want a hex editor, then display each byte as hex.

It will work fine so long as you use the virtual constructor and all your classes override that correctly. If you passed in an anon method that creates and returns a newly minted form, that would allow other constructors to be used. To me this is pointless though. It's a really common pattern, it's only a handful of lines. I don't really see the benefit. I mean, if you were trying to centralise some logging or other aspect, then it would make sense. Otherwise I don't really see the benefit. Also the name sucks. Should include the fact that the form is shown modally.

Well you have all of the information you need in a byte array. The index into the array is the address, and the byte value at that index is your value. Job done.

You already read every byte!! The real problem here is that you can't explain what you are trying to do. What do you mean about getting every address? An exe file isn't a list of addresses.

Then why do you try to convert to a string as if it were UTF16? You seem very confused. Well, yeah, it probably isn't UTF16 is it? It looks like you tried 10 things at random and left them all in the code you posted.

The size of the file is AFile.Size. You read the entire file into a byte array, but then go at the same stream with a binary reader. There are so many mistakes here. Do you want to read it into a byte array and covert to string. Or do you want to read it as binary.

For example this 10 year old answer has example code https://stackoverflow.com/a/5133222/505088 I think I've made a few minor improvements to this over the years, but the code here works fine.

Well you likely will break the existing app. It's easy to do what I described.

Not if the comctl v6 manifest hasn't been activated in your thread. You'll have comctl v5.8. You need to activate the comctl v6 manifest whenever your DLL is called and deactivate whenever it returns. Every function should activate on entry, deactivate on exit. I do this in my Excel com add in.

Pictures or icons? Kind of a big difference.

Er, C handles floats fine, better than Delphi as it happens. Ha ha

There's never been any point in using anything other than C to write device drivers on Windows or Linux. It's not like you can take advantage of OOP in the context of a device driver.

That's a tool chain limitation rather than language though.

Hard to see how REST could achieve that. You likely need to find a programmer.