David Heffernan

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

1 hour ago, Joseph MItzen said:

It's not so simple in Delphi though.

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. 

8 hours ago, Darian Miller said:

Sometimes you have to tell the money people NO

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? 

4 hours ago, timfrost said:

It sounds as if in your VT1mousedown event you should first call vt1.GetHitTestInfoAt to find out whether the mouse has been clicked on a node or not.  Once you have the node, it is up to you to work out what you have put in it and whether it is a selected/focused node, and what to do with it if so.  Presumably you always ensure that there is a node type or tag in the nodedata. 

 

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. 

18 minutes ago, Dalija Prasnikar said:

In addition to what @Stefan Glienke said, on Delphi LLVM based compilers exception triggered by accessing nil reference will wreak havoc because it will not be caught by current method exception handlers (and finally blocks will not be executed either) 

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

28 minutes ago, Stefan Glienke said:

everyone knows what an access violation at 0x0071f2a7: read of address 0x000000f7 means, right?

Erm, yes. 

54 minutes ago, Uwe Raabe said:

Because I can set up my IDE to skip EParameterCannotBeNil exceptions in the debugger, while still catching other nil pointers.

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. 

24 minutes ago, Schokohase said:

Because of fail fast

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

6 hours ago, PeterBelow said:

 

I usually test for pre and postconditions like this:

 

procedure TBlobDB.CreateNewDatabase(aDBStream, aIndexStream: TStream;
    aTakeStreamOwnership: boolean);
const
  Procname = 'TBlobDB.CreateNewDatabase';
begin
  if not Assigned(aDBStream) then
    raise EParameterCannotBeNil.Create(Procname,'aDBStream');
  if not Assigned(aIndexStream) then
    raise EParameterCannotBeNil.Create(Procname,'aIndexStream');

This is for errors that are supposed to be found and fixed during the testing phase or (for library code) in unit tests. For user input the input is validated before it is used by the program, if this is at all feasable. The end user should never see an exception coming from parameter validation at a lower level, in my opinion, since the UI context may not be evident at that point and it may be unclear to the user what he did wrong.

 

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

34 minutes ago, David Schwartz said:

Yeah, I've suffered through using that sucker a few times. I think it's more work than I want to put in.

 

Any other ideas?

 

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