David Heffernan

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.

This is simple to answer. Measure the time of the program running. Everything else is pointless. Don't guess performance questions. Measure.

It will be shutdown when the OS updates. Also, if you want to make it hot upgradeable, make a monlotihic DLL hosted in a thin executable.

Build a monolithic executable and then the problems disappear.

I've wrapped libyaml, which is a bit of a grind but very functional.

But none of that complexity is present here. And even if it was, then you'd still use CreateProcess. ShellExecuteEx would have value with the runas verb only.

Whatever the problem is, trying to hijack keypresses handled by the system is not the solution

No. But then the user with such a monitor will notice and increase the DPI. Such a problem will affect all programs. You certainly don't need a 4k monitor to test DPI scaling but you do need multiple monitors to test per monitor DPI scaling.

I know, but if you want to break on an exception, why would you disable that? Writing naff code instead of using the tools of the debugger is pointless. My question was rhetorical. If you disable debugging, it would be odd to then jump through hoops to debug your program.

But how do you break there if you disable debugging?

Very bad idea to use the distance since that involves sqrt. Do the searching with sqr distance and only call sqrt when you have the closest point.

Surely you just call CreateProcess directly

Out of the three options, the first two are fine, the last one is a terrible idea. Don't do it. You just create loads of extra work for no benefit.

You aren't really naming the units with numeric suffices, surely. If you actually are doing that, put them all in the same unit.

Pointless to ask ShellExecute to create a cmd process to in turn create another process. Create the other process directly. This is the source of all your problems.