Leaderboard

I just looked at FGX, it doesn't look like it supports an alternative to TWebBrowser. And I would like to stick with Delphi, I have developed a lot for it and have a lot of pre-built support code that allows me to quickly prototype. Otherwise I would have already moved to ReactJS, Kotlin or Flutter as you mentioned.

If the code you posted is all the class constructor does it's pointless anyway as string variables don't have to be initialized to empty string.

I remember that as well..a bit sad in my view. So, there is Embarcadero and then there is Delphi's Product Manager. I wonder how this works... Feels like the product manager is a freelance and outsourced position

Yes, it works (I was able to connect, upload and download files). Probably I would have to set file rights after upload (it was uploaded to linux server, file rights were set to 000). Paradox is, that customer prefers something with support, so I had to buy Devarts SecureBridge Standard...

Since Rio it has Z-Order for Android too.

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.

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.

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.

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

and what if the db changes in the meantime?

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.

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.

They're unknown internally too. I'll never forget the time Marco scheduled a preview webinar for an upcoming release and Embarcadero went and released it two or three days before the preview was scheduled! Marco joked it was now a "postview webinar", but it struck me as strange that not even the project manager had any idea when the product would be released.