David Heffernan

It's very hard to reproduce the exact series of steps which are undertaken when sending an email. And why bother? Since you have to handle the case when it fails for real, why not use that? The best code is the code that doesn't exist. Can't be a defect in code that doesn't exist.

I expect that if you do that you'll have clients complaining that your program refuses to send mail when it would succeed if it tried to do so.

You have to deal with any errors that arise when you try it for real. Why do you feel the need to do more?

Exactly this.

How easy does it seem right now?

Why would any professional programmer be using getit anyway? As I understand it, it is suitable for hobbyists and no more.

Doesn't sound likely to me at all. Do you understand why I suggest to mask floating point exceptions when calling into other code?

I guess you need to mask floating point exceptions before calling in to the dll. https://stackoverflow.com/q/19187479/505088

Thanks. Actually I think we agree on most things, we just have a disagreement on the mechanics of SO. I don't think that's very important in the grand scheme of things, and I am extremely appreciative and admiring of all the good work you do in the Delphi community.

Perhaps this comes down to perception, and the type of work involved, and the other attractions of the company, but personally I hire programmers. If they don't know a specific language when they arrive, we teach them that language. I don't really buy in to the idea that there are Java programmers and C# programmers and Python programmers and so on. In my mind there are just programmers.

Sadly, I've not seen much that gives me cause for optimism.

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.