David Heffernan

57 minutes ago, Mahdi Safsafi said:

I really don't understand why someone will not use OS functions

Premature optimisation 

7 hours ago, Remy Lebeau said:

make the layered window be a top-level overlay window that follows the panel onscreen.

Yes, that's what I envisage

Can't understand why you aren't calling GetMem. 

Another option is to use a layered window to add the additional painting. This is very flexible, not limited to panels, doesn't require any changes to the implementation of the controls. 

Two things can happen

1. The constructor succeeds and returns a valid object reference. 

2. An exception is raised, propagates out of the constructor, and the assignment never happens. 

The try finally here isn't protecting the execution of the constructor. It protects against exceptions in the code that runs after the constructor completes, after the try.

Look at the code in your post. The try finally is not active when the constructor runs. If an exception is raised in the constructor then the try is never reached.

So, yes, you do need the try finally. 

10 minutes ago, Mike Torrettinni said:

I thought he was referring to record helpers.

I literally wrote class helpers. 

2 hours ago, Mike Torrettinni said:

Whenever I think about these I remember 'you can only have 1 active record helper at a time...' and I stop as I have no idea if that means it will stop other helpers working.

It will. That's a problem if you are using other helpers for the class. Are you? 

3 hours ago, Mike Torrettinni said:

You can't always extend some things, right? Records are one of them... for example: I used to have xml library that had XMLNode.GetAttributeAsInteger, the new (better) xml library doesn't. So, since .ToInteger fails on empty strings, and I prefer using StrToIntDef as little as possible, I just added the new method to the library source.

This is what class helpers are for. 

3 hours ago, Mike Torrettinni said:

Or Virtualtreeview - for years I had my own AutoFitColumnWidthIncludingCaption, which was implemented I think in one of the latest updates (this or last year) -so I guess I will not need this patch anymore.

Likewise. 

It's possible that the changes you are making to the third party code should be made in your code instead, thus side stepping the problem. 

6 hours ago, johnnydp said:

I've just read that:

https://community.idera.com/developer-tools/b/blog/posts/c-builder-and-platforms-support

A painful read from a development team that has bitten off way more than it can chew. 

Doesn't seem plausible. FileExists doesn't care about spaces. You'll want to do some debugging on a machine that exhibits the behaviour. 

16 minutes ago, RDP1974 said:

better to wait Embarcadero support for AVX into Delphi asm ... need too much time and easy to do errors

could be a long wait

3 hours ago, Angus Robertson said:

InterlockedIncrement

Replace that with AtomicIncrement or the Increment method from System.SyncObjs.TInterlocked

Problem could be how you call the function 

2 hours ago, Mike Torrettinni said:

I assume the combination is good for teams, rather than single developers.

It really makes not a lot of difference which vcs you use, compared to not using revision control. 

If your program requires the covered code in order to function then I think your code needs to also be GPL. Worth talking to the developer of the code. Often they will dual license for such eventualities. 

17 minutes ago, luebbe said:

Although it doesn't get as many updates anymore as it did in the first year.

Probably it is mature now.

9 minutes ago, chkaufmann said:

So just that I get it right: Because my return value is an interface type, the compiler adds something like this as first statement of the method:

 

Result := nil;

Not quite. The default initialisation is outside the function. 

You don't get this because the return type is a managed type and so is actually passed as an extra var parameter. So the variable is assumed to have been default initialised outside the function. 

I'm not trying to defend the compiler design here. The handling of function return variables is a complete mess in my view. They should be passed by value from callee to caller. The whole hidden var param is a weird hack from the ancient past that should never have been done. 

https://stackoverflow.com/questions/63111541/omnithread-delphi-many-calls-in-the-same-function

For reference, here is the same Q on SO

Adding madExcept or EurekaLog or similar is the obvious way to find out what is going on here. 

2 hours ago, Arnaud Bouchez said:

It occurred to Eric at least with DWS. He actually monitored it before fixing it.
Of course, he dealt with a language compiler and execution stack, but I guess a lot of other kind of projects may have very tiny objects - if the SOLID principles are properly followed.

I'm not denying the existence of the problem.  I'm just putting up a flag to say that I believe that in a great many codebases you are very unlikely to encounter it.

So, don't get to too stressed about this, and perhaps don't worry about trying to fix the problem unless you know for sure that you are affected by it.

It's pretty unlikely to encounter this issue in real code. 

I always turn off stack checking for this reason.

Wouldn't it just be better to put it in a DLL? 

Just compile the C++ code with options that suppress stack checking.

Seriously though, putting all this in a DLL is a far better approach.