David Heffernan

What the heck does this mean? People are trying to help you and the fact that you can't recognise it doesn't mean that they are unprofessional.

Here is the list of language improvements: binary integral literals (i.e. %0101 which equals 5 in decimal) _ can be used as a digit separator for integral literals, e.g. const oneMillion = 1_000_000 (essentially the parser just ignores _ when parsing such literals) inline asm support for AVX-512 instructions Kinda lame that this is all there is. What's new here: https://docwiki.embarcadero.com/RADStudio/Alexandria/en/What's_New

no, nor any improvement in the codegen so far as I could tell

Certainly your settings could be relevant.

Everything that you create by hand (as opposed to being created by a script) goes under revision control

I think you need to write a short but complete program that demonstrates the issue. Otherwise it requires us to guess which is not effective or efficient.

Why wouldn't you automate the build?

I guess you mean dpr not dfm. But even that sometimes is not enough. Because the units won't be initialised in the order the appear in the dpr. The first unit in the dpr will use other units and that influences initialisation order too.

It's almost as if this thread didn't happen! What have we been talking about before now???

It's not that people have tweaked the system. They've just chosen to associate the PDF extension with a program that chooses to use different verbs as default. That contradicts your earlier points where you said double click on PDF is the same as invoking open verb.

It's not pointless. It's really important to know how the system works. These details matter. Details are important when programming. Makes no sense to recommend the 99.99% correct option over the 100% correct option. Obviously it's not likely to go wrong, but once you know how the system works why on earth would anybody opt to make an intentional mistake?

Not necessarily. For instance if your dpr file references them in the other order then it won't be that way. And other unit use clauses can confound you. Enforcing dependencies in initialisation order is not robust. I prefer to find a different way to solve such problems.

No. This missing context is the exact reason why this thread has been so long. It's invariably valuable to understand the motivation to a question. It sounds like what you need is for you r the calling processes to provide extra information to your program.

Then you are in trouble because there's really no way in general to be sure that the process which created your process still exists when your process executes. Windows has a very different model of parent/child process relationships from say Linux. What problem are you trying to solve?

Not if the parent chooses to specify a different current directory. The command interpreter process, which is the parent, might terminate before your process has a chance to inspect it. If you are in charge of creating the process, then pass in the information required as an argument. The more I read of thus the more it seems you are taking the wrong path.

So you agree with me then.

What problem are you trying to solve here, because what you are describing doesn't sound like a robust solution to any problem.

Class constructors are called from the initialization section of the unit where the class is declared. So in your scenario it depends on the initialization order, and therefore it is not guaranteed that the class constructor is called before class methods are called.

Why is this so hard?

This is simply not true. If depends entirely on how the file association has been registered. Which depends on which program is controlling that association. Easy to imagine that UltraHyperMegaPDF might do it differently from other programs.

My advice is to show your code, a complete program, a console app say. This will include the call to CreateProcess or ShellExecuteEx. With the full path to the executable. And with error checking code included.

Is that true? Doesn't double click in explorer map to the default verb, which may not be open.

If you are going to start a new process, as your code does here, then you should use CreateProcess. ShellExecute is for invoking shell verbs. I mean, it will start new processes, but if you know you want to start a new process, you may as well do so rather than get a third party to do it. If you are going to invoke a shell verb you should always use ShellExecuteEx. ShellExecute has been obsolete for over 20 years now. The primary benefit of ShellExecuteEx is that it handles errors in a rational manner. As for your issue, perhaps it's just that AcroRd32.exe can't be found. What happens when you supply a complete path?

Sure. I just read your very first post and my initial reaction was that you'd changed two things and the OP may have got the wrong impression that both were needed to resolve the compilation error.

The generic code doesn't refer to any methods, not that the interface even has a hy methods here.