David Heffernan

There are simply some rules of use for certain types of library that cannot be enforced effectively by the compiler, or even by runtime checks. For these rules you need documentation and developers that are prepared to read documentation. My personal view is that if a developer is not prepared to go to the trouble of reading the documentation, then any problems they have are their concern and not that of the library developer.

Can you show a minimal dpr file and tell us which version of Delphi you use.

It really is

Where are the attributes defined?

Posting here is not going to have any impact on development of the Delphi IDE by Embarcadero. You would need to submit a QP report, although I guess at least one already exists. I assumed that your post was driven by a desire to get something done. Which can only be to import some actual type libraries. Hence my comments.

Choosing a better tool for mobile development is surely an option

https://stackoverflow.com/q/19054789/505088 https://stackoverflow.com/q/19054789/505088

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.