David Heffernan

But when you make the application handle the popup parent, there's nothing to keep the modal form on top of the main form.

This conversation is going nowhere. You really do need to understand what popup parent is. 

You don't want to make the application window the popup parent. Then your dialog can appear behind the main form. You want the main form to be the popup parent. Which you can do in CreateParams, or by setting PopupParent.

It's important that you understand what popup parent aka Window owner in Windows terminology means. At the moment you seem to be trying stuff without understanding it. 

I think I already explained that destroying the window is the key to getting the behaviour you want. I gave you two options for doing that. 

I don't understand what you mean with these two handles. I guess you are talking about the popup parent. You can set this more easily with the VCL PopupParent property. The right thing to set it to is the main form. 

Do you understand what the popup parent is, aka window owner in Windows terminology? 

So I think that this behaviour happens because the window is not destroyed.  If you make the analagous WinForms app then you don't see this behaviour.  I believe that's because that framework destroys the window when the modal dialog is closed.

You can achieve the same thing by, guess what, destroying the form object.  That's really the best approach.  I can't stress strongly enough that's what you should do.

You could also achieve the same effect by forcing the window to be destroyed.  Call DestroyWindow on the modal form when it closes.  That forces windows recreation the next time you show it.  Perhaps that's safe to do.  I wouldn't do it.  I'd do it the right way.

Embarcadero are never going to "fix" this because it would require a complete redesign of the VCL.  Not going to happen.  

FWIW it is less nasty if you pass the main form as the owner of the dialog when you create it. You pass Application as the owner.

Actually, I'm not sure that's true having played around a bit more.

It's worth pointing out that this preview is drawn by the system. It's entirely plausible that there's nothing that Embarcadero could do to change the behaviour. 

OK. Carry on the way you are doing it, and accept the preview oddity. I'm just trying to describe how to avoid that. But maybe it's less important to you. 

So store the data in a collection and populate from that. Instant. And it's better not to use visual controls as data stores. They should just present views. Destroying the form when you close it solves your problem. And the performance issue is easily dealt with as I have described. 

1 hour ago, McScotty said:

The downside is simply speed.  If you have to fill a combobox with names for instance, doing this only once per application session is advantageous rather than destroying and having to fill the combo boxes again and again... 

Not so. Populating a combo takes no discernible time. Try measuring it. 

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. 

19 minutes ago, DevDude said:

the Anti-Virus company F-Secure is blocking your website

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.