David Heffernan

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.

Fork is highly regarded. I know that @Stefan Glienke has moved to using Fork having previously used SourceTree.

These doc links explain it Simple Types (Delphi) - RAD Studio (embarcadero.com) Scoped Enums (Delphi) - RAD Studio (embarcadero.com)

https://stackoverflow.com/questions/65186802/countdown-timer-in-delphi Please don't cross post, or if you do, refer to the preferred version.

Except the reality is that you do take care over the latter case that you use, even though the compiler ignores it. It's somewhat ironic that PascalCase is a thing if letter case doesn't matter in Pascal. When you choose names, you take care over the letter case that you use, and then you try to stick to that letter case when you use that name. Which to me is the clincher in why languages should be sensitive to letter case.

I'm sure @David Schwartz knows what rubber ducking is. If he didn't he'd just have typed it in to a search engine to find out. So I guess he didn't understand how rubber ducking applied here.

Doesn't matter how many threads you use. It's an issue with the Python GIL that requires special treatment with threads.

thread safe? · Issue #47 · pyscripter/python4delphi · GitHub

Do you need multiple modules? You talked about multiple modules to hold different data. But why does the data have to live in a module?