David Heffernan

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.

difficult to reconcile these two snippets

Did you submit a PR for these changes?

Did you submit a PR for these changes?

These sort of shitty posts are precisely why SO ask these questions.

I guess you should just hire a programmer to do the work for you, if you don't know where to start. You already suggested this. Do a kickstarter or similar.

I presume that they are concerned that their community isn't discriminating against any particular groups of people.

It's just a lexicographic order. If the primary comparison is equal, move on to the secondary etc until you separate the teams.

Delphi can access all Windows APIs and the best reference is MSDN.

Er, yes, that's what I meant to type