Sherlock

And in the end, what is the effort worth? Just to say: "In my product 1+1 is still 2 but it looks better than the others".

That will fail quickly for word wrapped captions.

I don't hate them, I just don't need them. 😉

I have gone through the code and replaced those pesky FreeAndNils with FreeMem or Dispose, whatever fit. It compiles fine now, but next step is to redesign the code to get rid of those ancient pointer thingies altogether. Quite annoying. Thanks everyone for your help and insight!

You could think that to be the reason, but I'm looking at code with tons of PArrayOfByte like what I posted. This seems like some very, very old code and an array of byte is rarely implemented as a class is it? Much less back in the olden days.

@Dalija Prasnikar Thank you! I thought that might be the reason. Which brings me to my earlier question: Why use FreeAndNil on Pointers in the first place? Do you have any idea?

So I've been digging into some component codes just for the heck of it, and stumbled across a whole lot of code like the following snippet: procedure Foo; var Bar: PArrayOfByte; begin // Do some more or less elaborate thing with Bar // and in the end FreeAndNil(Bar); end; Now, first off, that is not how I had understood FreeAndNil. I always thought it to be usable for object instances. Of course one could argue, that whatever is behind a pointer could be an object itself, but I mean some thingy that was created via a TObject.Create. And sure enough, Delphi 10.4 will no longer compile stunts like these. It will give an E2010 and bluntly state that TObject and PArrayOfByte are not compatible. And rightly so. So...What to do? How to fix? Given that (in the above crude example) Bar must have been allocated memory via System.GetMem or System.New, System.FreeMem or Sysem.Dispose will do the trick, right? Why was this not done in the first place, though? Why mix paradigms at the risk of creating some unholy entity mucking up the entire system? Perhaps looking into FreeAndNil will enlighten us? This is 10.3.1s take on that method: procedure FreeAndNil(var Obj); {$IF not Defined(AUTOREFCOUNT)} var Temp: TObject; begin Temp := TObject(Obj); Pointer(Obj) := nil; Temp.Free; end; {$ELSE} begin TObject(Obj) := nil; end; {$ENDIF} And here is what 10.4 considers to be correct: procedure FreeAndNil(const [ref] Obj: TObject); {$IF not Defined(AUTOREFCOUNT)} var Temp: TObject; begin Temp := Obj; TObject(Pointer(@Obj)^) := nil; Temp.Free; end; {$ELSE} begin Obj := nil; end; {$ENDIF} Subtle, innit? Now FreeAndNil requires the thing it's supposed to free and nil to be of TObject, which is cool. But it also considers it to be const...why is that? I learned const renders the parameter unmodifiable, see here: http://docwiki.embarcadero.com/RADStudio/Rio/en/Parameters_(Delphi)#Constant_Parameters. I also took a wrong turn somewhere and ended up in this C++ explantion of const http://docwiki.embarcadero.com/RADStudio/Rio/en/Const in detail this sentence: "A const pointer cannot be modified, though the object to which it points can be changed." OK, so we can change the object, we are freeing it after all. But then we also change where the pointer points to, by niling it. Now that should violate the const boundary, but it does not. Is it because of the "fancy shmancy" use of @s and ^s here? TObject(Pointer(@Obj)^) := nil; Why? Why go to the lenghts of casting, adressing and dereferencing? What are your thoughts and comments on this? I think this almost cured my urge to look into the sources of other people 🤣

German is OK as well I would always use indexed format specifiers though.

Sorry, didn't catch the subform. Can't help then.

We are not aware of the complete wording of said offer, that is something between Andreas and Embarcadero. What we do know from past statements however, is that some form of NDA or other contracts might be involved. But lets not speculate. IDEFixPAck will come once Andreas gets to install a 10.4 CE, which will come out with 10.4.1. So keep your fingers crossed, that this well be soon enough.

Do you mean named pipes?

Of course you might exclude existing users. Those with 32Bit iOS. How many are there, though? What do you know about your users? Do you have any information? However, that still wont lead to a new AppID.

I totally understand, but some eye candy just wont work. And sooner or later some other stuff will follow. This discussion is as old as Windows itself. It used to be "my customers only run DOS" then became "my customers only run 16Bit Windows" over to "my customers only run WinXP" to what we have today. Someone in that story has not learned, and should be beaten with a set of Windows installation floppies: Hardware manufacturers that create one version of their controlling software and never update it, or for an ungodly price. We could break our ears and keep our software running on DOS, or just inform the customers and let them wise up and do a pitchfork and torch run on their machine manufacturer. After all, it is your hide they'll be after if something wont work because their system is outdated - not that this is the case right now.

Thanks for the heads up. Did you report it at QP?