David Heffernan

No. Because there is no DllMain and so nothing is initialized. And then there are the lack of relocations. What's wrong with Delphi programmers. Read the standard output already!

Nope, that doesn't work. You can't expect to load an exe file with LoadLibrary. Also, even if you could, don't go exporting string across a module boundary. I'm astounded at all the posting here for a trivial problem with a standard solution.

The most reliable way to avoid the legion of bugs with this feature

Regarding a fix, this is only one of a number of problems with scope resolution in the language. Same issue arises when you use units, where more recently imported symbols hide those from units imported earlier. Same for local variables and methods. Same for local variables and global symbols. Anywhere where you refer to a symbol and there are multiple matches then the compiler chooses the most recent. In princple the resolution is simple. Introduce a new compiler warning whenever the compiler uses this most recent principle.

Debugging was never the issue. That was just annoying. Refactoring was never the issue either. That also is annoying but one of many broken aspects of the refactoring. The issue is the silent bugs that arise when you add a field to a type and that one hides local variables. This has been discussed hundreds of times. Try some more websearch. Then, stop using with.

Don't you just declare the property as TStrings? Use its Text property when you want a string representation including line feeds.

I am defending a very important, and very well respected, member of the Delphi community. That's all.

In defence of Mathias his madExcept library is superb and very actively maintained. And his response to your comments in the thread seem reasonable. Why expect him to work on freeware? Anything he does is a bonus. It looks like your frustration is getting the better of you.

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.