David Heffernan

Is that is a little bit loose? Consider The second const binds to what exactly? Not "the thing on its left".

I'd far sooner use Sender in an event handler to identify the control, and then have a map to anything else. Tag falls over as soon as you need to handle more than a single aspect. Plus there is no type safety.

I have never understood why Tag would ever be used. I mean I get it for a toy program knocked up in a couple of minutes. But not for real world code.

I'm sure you know how to work with list objects, and how to set the Visible property.

It's not at all difficult. Put them in a collection and hide all of them apart from the active one. Has the benefit of doing exactly what you want.

It would be far simpler to remove the page control and tabsheet and have the panel placed directly on the form.

For integer, due to assignment compatibility rules of the language, the only use is to provide a distinct type identity to be used in RTTI settings. For instance if you wanted to have a separate design time property editor for this type.

Distinct types don't give you type safety when used with integers and strings. These distinct types are still assignment compatible. There is a use in type identity for design time property editors. If you want type safety for assignment you'd need to wrap in a record.

All this speculation..... A minimal example and the answer would be simple.

I also talked about such examples. This isn't one of them. You said, "I'd understand if the logic was implemented in RecreateWnd but that's not the case here". You literally talk about making a choice based on the implementation details. I still can't see why you are set against calling RecreateWnd. That seems perverse to me.

Not so. For sure the language doesn't stop you using any message you like. But that doesn't mean that it is reasonable to do so. Oftentimes messages are used in the private implementation detail for a class. As a broad principle, you should not be looking to work with Windows messages when consuming VCL controls. Sometimes one is forced into it because the control provides no official mechanism. But when we do that, it is brittle, and subject to future implementation detail changes. And there it is. There's the point where you take a dependency on on implementation details. The implementation of RecreateWnd is: procedure TWinControl.RecreateWnd; begin if WindowHandle <> 0 then Perform(CM_RECREATEWND, 0, 0); end; There is a difference between this code and yours. Your code does something unconditionally. But RecreateWnd does nothing if the window handle has not already been created. I'm quite sure that you've got this wrong. I mean, it won't have any material impact on things, but one may as well do things the right way.

This doesn't make sense to me. I don't see the argument for sending a private implementation specific message rather than calling the RecreateWnd method.

Dude, just make a minimal example and debug that. Post it here if you want. Really good discipline to learn how to make that minimal example.

Cut this code down to the minimum that leaks. Then debug that.

Try finslly still wrong. You must acquire the resource immediately before the try Foo := TMyObject.Create; try Foo.Use; finally Foo.Free; end; As you have it, if an exception is raised before the variable is assigned, you'll call Free on an uninitialized variable.

Not the cause of the leak, but each of those calls to TSomeObject.Create needs to be protected in a try/finally

Free is implemented as if Assigned(Foo) then Foo.Destroy; so those if statements in the previous post are pointless. Call Free unconditionally.

Even harder than porting to delphi.

No. It's clear. He wants the address of the record stored internally by the class to avoid a copy.

What value of xxx is to be used?

"may" is rather weak. A more detailed clarification may be useful to the asker, to make it clear that the code you offered does not prevent a copy, and in fact just adds obfuscation. However, it's also possible that there is premature optimisation going on here.

Surely that's just going to copy the record to a temp local, and return the address of that temp local. Or am I missing something?

Then you end up with different names for the same thing. How can that be better? Refactoring tools get these names changed very reliably. I don't understand why people are scared of changing names. If you aren't prepared to change names then your code will be a mess.

Now you have the type named incorrectly in thousands of places. It should be called TItemExArray. Seems far worse to me.

I can't really see any benefit here. I mean you might think that TItemArray is somehow better than TArray<TItem> but they seem pretty interchangeable to me in terms of readability. And the reader has to trust that convention was followed with TItemArray.