David Heffernan

Didn't work out that way for the Linux compiler.

If the bulk of the codebase feels that they aren't getting value for money, they will stop paying. Which hurts you. Of course. You'd better hope that majority VCL customers keep paying. People have been declaring Windows dead for as long as they have been declaring Delphi dead. Making new delphi developers is easy. You just train your staff. They've been trying this for a long time now and the numbers aren't great.

64 bit Windows compiler that generates efficient code

Which is my point. I find it galling that the overwhelming majority of Delphi users are maintaining and developing existing code bases on Windows. These are the people that are paying Embarcadero. So why are their needs neglected?

Why would you expect it to be faster? Why would you expect it to be significantly faster? What sort of code do you expect to be faster?

Bit you can't see the string.Empty or '' instances. Having lots of different ways to say the same thing just makes life harder.

I wasn't suggesting that removing forms was the ultimate solution. I'm giving you debugging tips. At some point, you'll have to do some debugging. And no, I don't mean debugging with the IDE debugger.

But there's nothing else that it could be. I personally don't find it useful. I don't think it's confusing, I just think it is silly.

I'm not confused, but I think it's a bit pointless though. It's like having a named constant with a value of nil. Or a constant named Zero. What else could EmptyString be?

I've no idea, never needed to try. Not even sure that there is a limit, or what it is. But if you take out some other forms and the build succeeds then that is very strong evidence. How do you even begin to test 2000 forms? I just can't get me head around this at all.

Is it possible that you have reached the upper size limit for resources? Try removing some other forms and see if the project builds. That would strengthen this hypothesis. I can't begin to understand how you end up with 2000 forms in a single executable.

He is still going strong with the Graun!

Which part don't you know how to do? On Windows at least it's a call to CreateProcess, then close the app, and then a wait function call. Do you know how to close your app? If so all that is left is CreateProcess and a wait call.

Easy 1. Create the new process passing in the pid of the previous process. 2. Close the previous process. 3. When the new process starts, have it wait until the previous process has terminated before it shows UI.

QC is always updated later

Nobody other than you knows where this handle comes from. For all we know you've got a simple 32/64 bit truncation error. But we can't see the relevant code.

Given that you are the only one with any code, and any ability to debug, you are best placed to investigate. My advice is to stop guessing and do some old fashioned debugging.

Well, apparently GlobalLock failed with an invalid handle. Why is that? You need to work out where Handle came from and why it is not valid.

You really want to do this in an automated way, so that you can build in a scripted fashion.

No. What was meant was that the IDE could in principle use new style RTTI to locate private declarations. But it doesn't. It still relies on old style RTTI. I see no reason to expect this to change.

Win64 anyone?

Actually, the component will be created at runtime even if its associated field is private, or indeed not existent. What happens is that the streaming framework creates the component, assigns it properties, but is unable to field a field into which to store the reference to the component.

This information is documented http://docwiki.embarcadero.com/RADStudio/Rio/en/Delphi_Compiler_Directives_(List)_Index

Hmm. Seems like an odd way to go about it. Choosing to contribute to an open source project means making a commitment. I personally wouldn't want to do that without knowing that the project will have strong leadership and values. Making a an empty box and asking people to throw stuff in it as they please isn't at all enticing.

This is environmental. The behaviour you describe is not what I encounter. We need to understand your environment and workflow.