David Heffernan

What pay rate are you offering?

Log the floating point control word and see if it is the same in the two programs.

Use a list view. Part of problem solving is exploring the problem space and finding the best solution, given the pros and cons of all possible options. Deciding on the solution first and then trying to force it to work is not the way to solve problems.

Nothing fundamentally wrong with your option 1, so long as that is the single place where those string literals are written. The array does have the useful benefit of leading to helpful compiler error when enums extended, as discussed. But yeah, none of these options is especially terrible. I'd actually rate option 2 as the worst.

What's your definition of magic string?

Speed isn't the issue. The mistake that you make again and again. Maintainability is the only concern here.

So, the answer is a definitive no. Yeah, you are right, I just assumed that typed constants would be placed in read only memory, as they are in other tool chains. Oh well.

Aren't they placed in read only memory?

Attribute syntax demands true constants

Given this definition type Real = Double; I'd say you don't have much to fear. Of course, this code doesn't compile.

Why do this in a thread? Seems like much complexity for no possible gain.

It's not going to be sent many messages. Can you reproduce the behaviour in a cut down program?

The setup is pretty opaque for us here. These are the sort of details that matter. Without them it's just guesswork.

Make a note of the coordinates in the code that handles the button click event, and pass that on to other other code. I'm assuming that you are in control of all of the code.

You should check that Length(Str)=1. This fails of course, it doesn't compile. But it's not the code that was suggested. You should take more care when copying code.

Wbat if there are more than 26 columns?

Seems like you should be building the GUI in code rather than the designer.

Who are you hoping does this? i.e. who is "you" in your question?

Nah, that's not going be to the cause of the error reported in the original post. Hard to say what is the problem though without knowing the other side of the interface. How can we know how the function is declared in labview? My expectation is that the real issue is a mismatch at the binary interface layer.

The thing is, both resizing and compression will change the image and only you can judge which you prefer. It depends on what you are trying to do with these images, what sort of images they are. In my view you need to engage with that side of things first, not in a coding setting, to work out precisely what transformation you want. Then implementing it in code should be simple.

Do you want to resize the image or increase the compression? And which framework, vcl or fmx? And if you want to resize, what resampling do you want to use?

It's also pointless to use SetLength in this code because you then throw that array away and replace with a new one.

Isn't that what Ord() is for?

That returns a UTF-8 encoded byte array which you can copy into your record. Are you familiar with TEncoding, it's a somewhat import tool for text encodings?

TEncoding.UTF8.GetBytes