David Heffernan

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. 

7 hours ago, Schokohase said:

Well, if you pass a pointer to memory from your own process you should not be surprised that you can modify the memory you are pointing at. I would be surprised if I could not.

In C++ you can prevent it from happening. 

1 hour ago, Uwe Raabe said:

It is still possible to change the fields of a const record parameter when you use one of its own methods to do that.

This is still an enormous weakness in the language. 

1 hour ago, Kryvich said:

@David Heffernan Pascal was designed by Wirth with a Static  Strong  Safe typing in mind. The proposed compiler warning follows this concept. It can help prevent some semantic errors and write a clean code, without the need to complicate a code by introducing new structured types. So It's good for Delphi programmers and for Delphi, a win-win situation.

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.

4 hours ago, Kryvich said:

Yes, wrapping to the record type is possible. Though having the [optional] strong type checking for these types would be better. Detecting a possible error at compile time is much better than at runtime, right? The language already has everything to implement this:

type
  // Aliases, no type checking on assignment
  TDistanceMeters = Double;
  TDistanceMiles = Double;
  // New custom types, [optional] type checking on assignment is needed
  TDistanceMeters = type Double;
  TDistanceMiles = type Double;

 

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

3 hours ago, Kryvich said:

@David Heffernan No need to change the language. We need a small revision of the compiler so that it shows a hint or warning.

Such checks can be added to a third-party tool similar to FixInsight. But having additional type checking right in the compiler would be much better.

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.

On 11/9/2018 at 8:52 AM, Stefan Glienke said:

Well you have a different definition then than Intel in paragraph 8.1.1 it seems.

So unaligned data can be as well part of a struct/record which fits into a cache line and thus is guaranteed to be atomic.

Fair enough.

7 hours ago, Kryvich said:

Slides 74-76. Strongly-Typed Pascal !!! 

Someone in Embarcadero should hear programmers request and help to make the implicit explicit in such situations:

program TestMetersToMiles;
{$APPTYPE CONSOLE}
type
  TDistanceMeters = type Double;
  TDistanceMiles = type Double;

function ConvertMetersToMiles(Distance: TDistanceMeters): TDistanceMiles;
begin
  Result := TDistanceMiles(Double(Distance) / 100000 * 62.14);
end;

var
  meters: TDistanceMeters;
  miles: TDistanceMiles;
begin
  miles := 100; // No syntax error, no warning, no hint
  meters := ConvertMetersToMiles(miles); // No syntax error, no warning, no hint
end.

I've complained already about this here.

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. 

59 minutes ago, Zacherl said:

It's okay man. Can't help it, if you don't want to read the complete post (e.g. the text i quoted from the Intel SDM). I'm out.

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

22 hours ago, Zacherl said:

Reading unaligned values from memory is slow but should still be atomic (on a Pentium6 and newer). 

That's what you said.

7 hours ago, Zacherl said:

Sorry, but did you actually read my post? 

 

Thats exactly what I quoted from the latest Intel SDM:

 

Can you please give me some references that proof your statement? Intel SDM says (you might be correct for normal data access, but using the `LOCK` prefix is something else):

 

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

19 hours ago, Markus Kinzler said:

On one side EMBT removes "automatic" management for classes (ARC) on the other hand they introduce automatisms for "static" types. It might be dangerous. Is there a way to off switch this (useful) feature?

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

On 11/6/2018 at 2:30 PM, Jacek Laskowski said:

Is writing and reading 1 byte (type Byte) always atomic (and safe) operation?

 

Is writing and reading 2 byte (type Word) always atomic (and safe) operation?

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. 

8 hours ago, Zacherl said:

Reading unaligned values from memory is slow but should still be atomic (on a Pentium6 and newer). 

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. 

22 hours ago, Zacherl said:

That's exactly the problem and as well the reason for the warning. The OP does not  actually override TObject.ToString but introduces a new method (because of the different signature). The override just does nothing. 

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?