David Heffernan

It doesn't seem to me to be stupid to want to use arrays and operators together.

You must have all the versions that you use, so you can answer this by inspection.

You can tell it must be stdcall since that is the only convention supported by classic VB.

I know I go on about this but it's really important, in my view, to stress that the testing framework doesn't discover the bugs. It's the developer that writes good tests that discover the bugs. You need a testing framework to help manage the test code. But the strength of the test is always the quality of the test code rather than the framework. There are plenty of libraries that ostensibly have test suites but are full of bugs because the test suites are incomplete.

What about the people who you are asking for help? I would post on one site first, and if you don't get a good response, then post elsewhere, with link to the first place.

There are no newsgroups here.

The curse of cross posting ......

That's exactly what I suggested if you read on to the second paragraph.

That SO topic is the same issue as yours. You might have to do a bit of research starting there. What you need to do is find the child process that actually implements the app. Lots of code examples to do that.

That's the name of the executing process. Asker wants to know about external processes.

Well, nobody really knows what that is. But your question is how to find the name of a UWP app from a top level window handle. Which is a question asked here https://stackoverflow.com/q/32001621/505088

So I guess you are happy to rely on the left to right order ......

No point planning for a future you can't see. The real problem was the stupid design in adding Create and Free methods that serve no purpose and confusing so many people. Best strategy is to use a singleton for the context.

You are quite wrong. No point freeing it. No point even creating it.

It's not possible. How could it be?

If the goal is to use RTTI then it seems questionable to use compile time generics. Will result in generic bloat. May as well pass the address of the record and the type info. Or if you want to ensure type safety have the generic method call a further helper method that is non-generic and receives the address of the record and the type info. That avoids the bloat and gives benefit of type safety.

How will you use RTTI with this?

It's a typo. Should be SSCCE: http://sscce.org/

The point about the order was to be sure that the condition was evaluated. Consider the two settings for the switch: 1. Left to right, condition is first sub expression, therefore it is evaluated. 2. Complete eval, all sub expressions are evaluated, therefore it is evaluated. QED

You can count on it. http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Expressions_(Delphi)#Complete_Versus_Short-Circuit_Boolean_Evaluation Very surprised you don't know this.

Nothing to do with implementation details. The Python syntax is simply the Python equivalent of the C conditional operator. You know, the operator that is missing from Delphi.

It's an extra step for every one of your readers. In fact it's multiple steps. Down file. Unzip file. One goal of the writer is to make it easier for the reader to see and understand. For instance, if I was on a mobile device how would I read files in a zip file?

That's certainly more concise but it has a completely different meaning. Think about it Rudy.

Seems kind of a waste of time this entire discussion. The language is well documented and is quite concise. The are only a handful of conditional statements. The syntax for if is clear. You have to write the code in the language that is provided to you. Use an if statement. End of story.

So you know the answer