David Heffernan

It was you that referred to jagged arrays. Once you start using them, for rectangular data, you've given up caring about performance. I didn't see any copying when I looked at this. I don't see any evidence that performance is a significant issue here.

I wouldn't overplay this. Jagged arrays have terrible performance. Your problem is not that all these ReallocMems can be skipped, but aren't. Your problem is that you are using a jagged array rather than a multidimensional array. Your problem is that you did 101 allocations (not 1000) rather than 1.

It's just a realloc of a block the same size, which is a null op and nothing happens. Unless you have a pathologically insane memory manager. But no memory manager I know of would do anything other than null op for this realloc.

But, at the end, do you, or do you not, end up with an array that is the correct length, and respects the contents that existed before you called SetLength? If perhaps you are worried that there is a performance hit, measure it. I can't believe we would still be having this debate about premature optimisation. You remember us mentioning this to you before? If you want to make your code run faster, why don't you optimise the parts that take the most time?

Why would a check be needed? What is the defect that you are claiming because there is no check?

What difference would that make?

I'm struggling to appreciate what the problem is. I don't think SetLength behaves incorrectly. Am I missing something?

This could be pretty expensive if the task is short lived. As a general rule, the owner of the thread should take charge of initialising COM. In this case it's probably the thread pool. I'd be looking for a feature of the threadpool whereby the client could request that threads created by the thread pool come initialised for COM. Then the initialisation can happen once for each thread, rather than for each task.

The months between now and a fixed date in the future do have known numbers of days.

^^^ this

I think this desire to prefix everything is not helpful. I can't see what you are gaining by doing it. And doing so introduces a risk that you will read meaning into something that the compiler does not. Which means that if you ever forget to use your chosen prefix, or use a variable defined in a unit outside your control, you might infer the wrong thing. I personally use F for fields, and T for types, and nothing else. I use F for fields to avoid a clash with properties. I think the language design pretty much forces us to do that. As for types, that's more of a historical choice. I think if I didn't already have a heap of code written that way. Wouldn't your time be better spent improving your code rather than agonising of which letter to use as a prefix? If you decide to prefix your names, then pick a system and stick to it. It doesn't matter which letters you choose!

I don't think that's a very helpful way to think about it. I would reserve the term local for a variable declared inside the body of a procedure. This includes any by value parameters. There are two main aspects at play here: lifetime and visibility. A local variable, as defined above, is created when the procedure is called and destroyed when the procedure returns. This is a narrow time frame of life, worth of the term local. A variable declared in a unit is created when the program starts and destroyed when it ends. That is a far wider time frame, and the term local is, in my view, ot befitting such a thing.

Every question you've asked in this thread has been answered now.

Do you do it for a reason? Surely these things should be intentional.

Why do variable names need a prefix?

@Remy read up to the part where all this happens in another process with, presumably, ReadProcessMemory.

For methods that are readily accessible you can use the idea given here (Delphi: Offset of record field - Stack Overflow), although in that Q it's in the context of records. Your TControl in the previous message has public methods, so that's easy. Your TWinControl has private methods so you'd need some form of cracker to gain access to the private methods. If it were me I'd copy the VCL unit, add it to my project, and add some code in the implementation section to dump out the info you require. Of course, the TControl that you quote here isn't the real TControl since the fields in the real one are private not public. So who knows what is really going on. Perhaps you are posting code from some experiment you are working on. Also, casting an HWND to a TControl* doesn't get you anywhere. They are not the same thing.

Kind of an important detail that you slipped in there. I'm going to be blunt here. The process of trying to offer help whereby you provide minimal details and then we try to piece together your environment with a game of 20 questions. Well, it's not productive. You haven't had a whole lot of success in this thread because you have been so economical with these details. Until you address this lack of detail, I predict nothing will change.

Does your code run in the same process as the Delphi program whose properties you are trying to inspect?

If what you are really asking about is the size of the instance, then use InstanceSize to find that out.

It seems like you might have asked the wrong question. It doesn't sound as though the size is that important. What you seem to be after is to capture the control's properties. Is that correct?

How it started. A brilliant tool that was miles ahead of anything else in its main sector. How it's going. A huge pile of bugs that is falling further and further behind the competition.

Whilst I am a fan of TortoiseSVN, I am not a fan of TortoiseGit. Having a tortoise in the name isn't enough.

They just cloned the typescript repo .....

It's easy to backup, and every cloned repo is a backup. It's not an issue particular to source code. Any cloud based storage comes with the same question. On premise has its own issues.