David Heffernan

8 hours ago, hsauro said:

Exactly that's why I was asking if there was a way to measure the actual amount of time spent in my process and not dealing with everything else which is unpredictable. 

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

4 hours ago, hsauro said:

I’ll try that, thanks.

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 

13 minutes ago, Silver Black said:

 

Gosh! That really amaze me... I couldn't imagine. So WinXP is no more supported. Quite a shame.

Thank you for the quick reply to both of you.

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. 

12 minutes ago, sh17 said:

you can check this

 

https://github.com/3F/DllExport

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. 

11 hours ago, Davide Visconti said:

You can write the new length of the string inside the AText[0]

I never try that and IMHO isn't an elegant solution but it should works... Fast enough.

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. 

4 hours ago, Neutral General said:

I've got an application (windows service) that (in the best case) shouldn't be shutdown ever. But there are going to be updates to the application. So in order to not have to shut down the whole service, the service is modular and can just temporary unload a DLL, update and then reload it. That's not really doable with a monolithic application.

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 

1 hour ago, dummzeuch said:

You won't notice if the text gets too small to read.

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. 

2 hours ago, dummzeuch said:

 

The option I was talking about is called "Notify on language exceptions".

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.