David Heffernan

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.

Does it compile if you write TestProc()

Isn't that just recompiling VS with the ARM compiler.

That makes sense if you write programs that only run on computers that you buy. I write programs that run on computers that other people buy. I suspect that others do likewise. So I'll need a compiler for any architecture that a large number of customers and potential customers use. Whether Windows on ARM64 will fit that description anytime soon, I've no idea.

You should profile your program to find out where the bottleneck is. Human intuition is usually wrong in such matters.

No. It is not possible to read an excel file without opening it. However, I suspect that what you actually want to do is to read such a file without using an Excel process via its COM API. If that is what you want to do then it is indeed possible.

If there are faster asm versions in the system unit, that work on x64, then they will be used. But you can't compile an x86 asm procedure in x64 and expect it to work. You need a bespoke x64 version. In other words, I don't think what you describe is going to be possible. What is your specific performance issue?

My user is administrator, but because of UAC I run by default with restricted rights, as a standard user. Only if necessary do I run a process elevated. Do you have UAC disabled?

Why? We stopped doing that when Vista came out.