David Heffernan

Scale it back to a small test program. As for what's wrong, the thing that keeps the window on top is the window owner property. In VCL that's known as popup parent. I know you want a quick answer but sometimes you have to work a bit. Make that minimal test program and the answer will be easy to find.

This doesn't make a lot of sense to me. Why would anyone want to use some random files whose history we have no knowledge of, when we can simply checkout the source from the repo and use it directly.

What you are looking for is the default behaviour. Clearly there is something in your code that changes this. The solution is not to ask for some new code to make this work for you. The solution is for you to remove or fix whatever it is in your code that has broken this behaviour. Start a brand new VCL app. This will come with a main form. Create a second form, and show it. Note how the second form can never be behind the main form.

Download the source from the repo and include it in your project

Compiler warnings, rather missing the point

Bug in your code. The inliner has no reason to pass any parameters because you told it the external function has none. If you want to use inline, and doing so removes the jmp leaving just a single call, then you need to declare the external function correctly. I think I already told you this on SO.

In C++ you can prevent it from happening.

This is still an enormous weakness in the language.

It's fairly clear that the Delphi language we are referring to was designed to make such types assignment compatible. That is made clear by the documentation for the Delphi language. There are other languages that have taken different approaches, but we aren't discussing those languages here. We are discussing Delphi. Whilst you might wish that a different decision had been taken, it wasn't. It's really not likely to change.

But the language was designed differently. Use records. What's so difficult about that?

Since the language regards these two types as assignment compatible, it's pretty hard to imagine adding warnings or hints when you write such assignments. Wrap the value in distinct record types.

Fair enough.

You'll need to declare two record types for this. The language isn't going to change now.

@Stefan Glienke And the existence of two byte data that cross cache lines shows that unaligned access is not atomic. When arguing about non deterministic properties like atomic access or thread safety the language used is a little different. When we say code is. It threadsafe we don't mean that it will always fail. We mean that we can't guarantee that it will always succeed. When we say memory reads are not atomic we don't mean that they won't always be read with multiple bus reads. We mean that we can't guarantee that they will always be read with a single bus read.

You agree then that unaligned access of data greater than a single byte is not atomic?

That's what you said.

Yes, I read what you wrote. What you wrote was wrong. You said nothing about cache lines.

There's nothing to switch off. You choose to switch it on on a type by type basis.

Single bytes are aligned, because they can't straddle cache lines. Reads are therefore atomic, because they are aligned. Two byte reads can straddle cache lines and unaligned reads are not atomic.

Actually both of these statements are wrong. Reading unaligned memory is not atomic for reads that straddle cache lines. And unaligned memory access is not slow on modern processors.

The IDE's tools aren't well designed in my view. Don't set the version information that way, instead make it part of your automated build process.

It's not that the override does nothing. There is no override. It makes no sense to me to reintroduce a method of that name.

Why don't you override the method from TObject?