David Heffernan

Operators are functions. There are certainly times when it might be useful to use arrays as operator arguments. I regret that the language designers have allowed literals to have meaning determined by context in various places. When there is insufficient context, as is inevitably the case on occasion, these kind of problems arise.

The design error is converting left button up into click. That's what Sertac said. Read his comment carefully. A click is button down, capture, button up.

This was already covered on SO https://stackoverflow.com/questions/54401270/when-i-perform-the-ondblclick-event-form1-to-open-form2-it-fires-the-oncellcl If you are going to cross post, please note the other places that you posted so that people don't duplicate work.

Doesn't sound like resource exhaustion is to blame. More likely plain defects in your code.

You don't need to keep forms alive to preserve settings because you don't store setting in form instances. You store them elsewhere.

It's not about the memory. It's about removing global variables that allow form instances to poke at each other's internals. It's analogous to making fields private rather than public.  Those form variables only exist because in Delphi 1 the designers were trying to ape functionality of VB.

The entire design seems wrong. Don't use a global variable for each form. Remove them. Use a local variable and destroy it when ShowModal returns.

But this topic concerns the 8 bits in a byte.

Who says that the variation isn't happening in your process?

You'll see similar results as you do presently I predict.

Ugh, a class allocated on dynamic memory just to do bit twiddling. What is so hard about the and operator?

Doesn't seem like a massive amount of variability. Probably depends on what your code does. You are measuring what is known as wall clock time. Total elapsed time. Why would you want to measure anything else? Wall clock time is the time as perceived by the users.

Define "pixel perfect" please

It hasn't been supported for years now. Use an old delphi version for legacy OS like XP.

Don't put them all over the code. Just don't!! There is always a better way.

The fundamental problem sounds like you have duplication of code. Attack that and the problem you describe simply disappears.

In other words, you added these options to your project.

Not much point creating an unmanaged wrapper when the library ships with one out of the box.

There's got to be a convention one way or another. Is it really that hard to grasp?

Generally multiple threads give performance benefits for cpu bound tasks. This one isn't cpu bound. So how do you imagine there to be any benefit?

Very hard to see anything useful coming from this. Can't imagine any way for Delphi to directly consume a managed assembly other than COM. I'd consider making your own COM wrapper of the assembly, using C#, or writing a Delphi wrapper around the C interface.

If it's a numeric column then surely it's always a number.

I don't see that you have to work with variants. I think you can work with text. I work with text when I use VTT.

You are working with Unicode strings so you will always get varUString. I don't know what you have against varUString. Surely you don't want to go back to ANSI strings which is what varString represents. VarAsType returns a variant. That's why you need a typecast to obtain other types. The entire question seems massively over complicated. In fact this is a common theme of the questions you ask. Don't take that the wrong way. But my most important advice to you is to try to simplify. You seem regularly to get tied in knots because you don't reduce the complexity in your thinking. In this instance, surely, you should be working with the user input as text. No need at all for variants in my opinion. Simply use TryStrToInt to check if a string value can be treated as an integer. And if there really is some need for variants due to motivations we cannot see then take care to understand what types they can hold. Make sure that you only ever add Unicode strings and integers and therefore only need to deal with those two var types. Raise assertion exceptions if you encounter other types. Make sure that you have good testing in place. Now, you probably think that you haven't got time for testing but what many people don't realise is that testing saves you time. Testing is what allows you to make changes to code without fear of breaking it.

No you can't.