David Heffernan

That's a bug to use that reference, so this issue can safely be ignored with regards FAN.

As an aside, even in Delphi there is no such need. You can write 'first line'#13#10'second line' And even then, concatenation of literals is performed by the compiler, so the above code would result in the same codegen as 'first line' + #13#10 + 'second line' Finally, it is usually preferable to use sLineBreak rather than #13#10 so that your code is more expressive, and platform independent.

So instead of code like obj.foo := obj.bar + 10; you prefer obj.setFoo(obj.getBar() + 10); or perhaps obj.setFoo(obj.getBar + 10); (note that I personally am not keen on being able to call a function without the parens because it leads to ambiguity for type inference)

These two statements appear in conflict with each other. Advocacy for using getter/setter methods directly, flies in the face of criticism that properties can't be passed as var or out params. Neither can methods.

Perhaps the data module isn't being destroyed. If you showed a minimal reproduction then we'd be able to tell.

The latter. If you include this gpl licensed component then that propagates.

There are times when this is desirable. It's a big weakness in my view that the type of a literal can be ambiguous.

Same for integers, right? We don't feel compelled to store pointers to integers in arrays very commonly, do we.

Pretty bad idea this. It's also attempting to solve a problem that doesn't exist. Like if I do this: i := 12; j := i; i := 14; I don't expect j to become 14. It's just value type semantics.

mLabelMatrix[i, j] or if you prefer mLabelMatrix[i][j] as documented in the link I gave you

That's odd because you already solved the problem properly. Why do you just give up?

LabelMatrix is a type. You need to declare a variable of that type. Why would you have a dynamic array if the dimensions are known. Also, why 11, 6 if it is 12x7. If it is a fixed size, declare it so. Structured Types (Delphi) - RAD Studio (embarcadero.com)

It's just a multidimensional array of record. You will need to decide whether it is zero based or one based, but your example above shows a range of at least 13 in the major axis.

Start from the actual program and remove things bit by bit. When you remove something and the behaviour changes, that's evidence.

It might well be difficult. But unless you are able to debug this yourself what option do you have. In fact if this was my code and I was debugging it, making a minimal reproduction would be how I would tackle it.

Can you cut this down to a minimal reproduction

Well, slipstream them in too. You should be able to deliver an environment that has any packages you need.

It's easy to use the Python embedded distribution, basically just a Zip file, and deploy that. You can slipstream modules into it as you please.

It was never correct to put it in the same finally as lifetime management. Of course it won't matter if it never throws an exception. But it's basic sound practise not to put multiple unrelated tasks in a finally block.

It's quite possible there will be consequences. Impossible to say without knowing what your code looks like. Perhaps there are dependencies that require forms to be destroyed in a particular order. The erroneous finally block where you call that CloseDataSets method as well as destroying a form isn't a great sign.

madExcept works fine a service for me. But if you have JCL Debug working then that's fine. In which case can you get a proper stack trace?

I mean you could just use madExcept and have a proper stack trace for all such occurrences

The try/finally coding in the above is incorrect. It should be: function EncodePDF(const AFileName: string): string; var inStream: TStream; outStream: TStringStream; begin inStream := TFileStream.Create(AFileName, fmOpenRead); try outStream := TStringStream.Create; try TNetEncoding.Base64.Encode(inStream, outStream); Result := outStream.DataString; finally outStream.Free; end; finally inStream.Free; end; end;

I'm not happy. Optional parens means that a symbol like MyFunc can mean either the procedure or the value returned by a call to the procedure. And there are times when that ambiguity can't be resolved by the compiler. Most commonly when MyFunc returns another procedural type. So when you write SomeFunc := MyFunc are you assigning MyFunc or MyFunc() to SomeFunc? It sucks that in Delphi there is this ambiguity. The ambiguity would not exist if () were not optional. Like they aren't in so many other better designed languages.

Clearly a bug. Is there a QP report already. If not submit one. This feature with Delphi where the function call parens can be omitted for parameterless functions was a terrible idea that should never have happened.