David Heffernan

Well, I guess it's clear now that the issue is not Delphi, but rather what your ActiveX control does. Perhaps it's worth asking the vendor.

What is the downside of creating the form when you need it and destroying it when it is closed?

Destroy the form when you close it. It's as simple as that. If you want to preserve some state between invocations, put that in a separate object. Forms should just present views anyway, and not be part of your apps business logic.

That's not an issue with focus. It's an issue with window owner, or popup parent in VCL terminology.

What happens if you don't call LoadFile?

I use them to apply the same options to all my various projects. They work quite nicely. It means that if ever I change an option, or make a new project, I can roll it out effortlessly, and with confidence.

This is the wrong way to deal with flicker. Do it the right way and this problem vanishes.

I'd start by identifying the problem. Don't try to solve problems you don't understand.

I'd want to fix the code first. There should be two try/finally blocks and no try/except block. MotionBitmap1.Canvas.Lock; try jpeg := TJPEGImage.Create; try jpeg.Assign(MotionBitmap1); jpeg.SaveToFile('D:\picture.jpg'); finally jpeg.Free; end; finally  MotionBitmap1.Canvas.Unlock; end; And I don't know whether or not the lock/unlock is necessary. Why did you include it? As for checking whether or not it worked, there's no point. What failure more do you have in mind?

Maybe this is time to do it the right way? Given that you have to change.

The value is that you have the images in a useful form, not trapped in some weirdo base16 dfm format. You have names for your images, and not just integer indices.

Images should not be stored in dfm files. They should be held in their original format and linked as resources.

Easily resolved by removing F-Secure. As with so many anti virus products the cure is so much worse than the disease.

This is a good example of why making a clean reproduction of an issue is such a useful discipline.

You can implement a helper the way you expect, but mutating methods on value types is troublesome. Imagine passing such a type as a const param and then calling such a method. Because Delphi lacks const methods (as found in C++), such things cause havoc.

I've not ever looked at this function but it's not hard to see what must be going on. There is no 4 byte string type. So you'll be getting a dynamic array back. And there will be a null terminator as there is for all non short string types. But since there is no compiler support for treating the type as a string, you just get the dyn array length function, which counts the null terminator.

I don't see how any of that impacts a unit testing library. I wouldn't describe that as unit testing. My take is that the if we had a single language then a well written library would naturally be cross platform. But Dalija is right, there are two languages, ARC and non ARC. And you are also right about the runners. If you expect GUI then they could require distinct UI.

Ugh. How could I have forgotten that Delphi is actually two different languages.

Yeah, I know what cross platform means. What would be platform specific about a unit testing library?

Surely all the widely know unit testing libraries are cross platform.

GetSystemMetrics is from Winapi.Windows. Use a find in files search of the rtl/vcl source to find which unit contains specific functions.

Doesn't seem very plausible that this is the case. And it's tricky for us to dig deeper into "one reason or another".

Given that you weren't aware of using, it seems that you may not be fluent and experienced with C++. Are you sure you are best placed to be offering critiques of the language? Certainly my experience of using local variables in C++ differs greatly from yours. It is incredibly valuable in my experience to declare local variables at the point of use and with a narrow scope.

The example here is of WH_MSGFILTER which I don't think does injection.

Inject code into every process