David Heffernan

You can locate the library and run the typelib importer on it using the command line tool. The format is the same for 32 and 64 bit. The issue is just that a 32 bit process doesn't see the 64 bit registry. But once you pass the 64 bit com dll to the type lib importer it will be fine. Often you just import the 32 bit version of the COM dll and the same import unit works for both.

There are plenty of command line tools for this.

I don't think that toml is widely used, although I admire its goals. I also believe that it has some limitations. And I don't think there is a Delphi parser for it.

I expect that's exactly what happened, many times, but the money people decided otherwise.

Yeah, seems pointless. Use YAML if you want more readable files.

Documentation is always an option. Don't rule it out.

Isn't this the wrong approach. Don't you use the REST API?

What if the user has clicked without using the mouse?

The downside of adding checks is that the code bloat is huge. Imagine a function that accepts three args and just forwards them on to another method. You then have three checks against nil, and a single line to forward the call. That burden adds up. Having this checked statically, or even at runtime like range checking would be a boon. Of course, none of that helps with the much more invidious error of passing a reference to an already destroyed object.

Not something I've ever experienced being a Windows only delphi dev.

Erm, yes.

Every function you write that accepts a reference type, you check that it is assigned on entry to the function?

Examples aren't much use without understanding the rationale behind them. If exceptions are a PITA you must be doing something wrong. It's error handling without exceptions that is a PITA.

Reasonable at certain interfaces between modules, but not in every single function.

Why even bother writing those checks? An exception will be raised as soon as you attempt to use the nil instances.

I guess it depends on what motivates you. Do you want to optimise for the quality of your program's UX, or is it more important to you that you can create the UX as quickly as possible, irrespective of how well it works?

It still says exceptions to me. But you say that you don't want to use exceptions. Can you explain why you don't want to use exceptions?

This isn't using exceptions for control flow. It's using exceptions to deal with invalid parameters. If you don't use exceptions, and you show a message dialog to the user then what is code going to do next? How are you going to avoid following the normal execution path. You can exit this function. But what about the caller? And its caller? And its caller? And what about when you run your code through your program's API rather than interactively. Pretty debilitating to show a dialog to an API user.

Best is to use exceptions of course

What is more important to you? A solution that works, and 1mb extra exe file size, or no solution and 1mb smaller exe size?

Depends on your program's requirements and memory usage patterns. What are you trying to achieve with a change of memory manager?

Attributes are fragile by design. The compiler cannot verify that you supplied the appropriate attributes to make your program work correctly. For example, at the outset of this thread you are faced with an attempt to pass a typed constant to an attribute constructor and the compiler objects. Well, remove the entire attribute declaration and now your program will compile.

VCL styles anybody?

Really? I think that new features are poorly documented, but long standing language features are actually well documented.

Except that it doesn't work. Doesn't handle errors at all. Also, it's fine that you don't want to disturb your code. But if you are going to offer up code as an example, it should be exemplary.