Brandon Staggs

If this is all for real, why would you care? Anyway, I am unaware that Embarcadero has any AI development at all, other than people who work for them with side projects for copilot-like integrations of other LLMs. This is a long way off from magically making your app for you, but if that is real, then what difference does it make who makes the tool you use? Because at that point, you aren't even using an IDE.... Personally, I think we are a LONG way off from any non-trivial software being programmed entirely from AI prompts. And given how Embacadero can hardly keep up with mobile platform updates, I am quite certain if that ever does happen, it'll be from someone else.

Why oh why would you write a for statement like that? As others already said, you're declaring a set, so you are getting the expected behavior. I presume in your mind you expect it to be treated like an array. If that is the case, then you need to use an array instead of a set.

Your mission, should you choose to accept it, is to find out which control has the canvas in that state and why.

For me the issue has always been LSP and code insight, which seem to work better with tidy uses clauses.

I can think of a lot of reasons why it isn't trivial to do. I have only used analysis tools for this once or twice. personally, when I think a unit needs this kind of housecleaning, I just comment out the uses clauses and add each one back in (also checking whether it needs to be in interface or not) as needed. Even that can be less-than-easy, since sometimes a unit is included just to get its initialization section executed.

Yeah, they are indeed mutually exclusive. Each unit has it's own dependencies. If you want the units listed in order of when they are needed, you aren't going to be able to make them look "tidy." Sounds like you want a hybrid approach. I don't see how that could be done without manual work, but besides, it would defeat your originally stated goal. Personally, I find the overhead of locating units during compilation to be insignificant, so I always prefer a logical ordering because my brain will be slowed down by illogical ordering more than the compiler will be sped up by it! I my experience, the only thing that really matters is not having unnecessary units in the interface section. Anything that isn't needed should be removed, and anything that isn't needed before the implementation section should be moved to the implementation section.

The terminology in the quoted text is muddy, IMO. Reintroduce does not affect the compiler other than suppressing a warning. You will get the same code emitted whether you omit the reintroduce keyword or include it. When you use the keyword you are just telling the compiler you intend to do something that kind of looks like a mistake (hiding the inherited method), because it is not common to declare a method in a child class that has the same name as a virtual/dynamic method in its parent and not also override it. (There are times where this makes sense but I personally try to avoid it because of the inevitable confusion it may cause down the road when it is forgotten this was done...) It's also sometimes the case that the inherited class changes: someone adds a new virtual method that didn't exist when the child class was designed, and now there is an unknown conflict; the warning is a good one so you can know this happened and deal with it accordingly. I can't understand from your post what you actually want to do, so I can't offer you an alternative that works around the confusion.

That post is extremely difficult to understand. Documentation is here: https://docwiki.embarcadero.com/RADStudio/Athens/en/Methods_(Delphi)#Overriding_versus_Hiding No, the purpose of reintroduce is to suppress the compiler's warning that you are hiding the inherited method. It is a way for you to tell the compiler that you know what you are doing and to not bother you about it.

Are you serious? Maybe let Adobe know they have useless color spaces in Premier? How do you think branding color matching from multiple color sources is done anyway?

Looks great! If you really want it overengineered add the various component video color spaces to. YCbCr component video (and YUV too) might actually be useful in the video editing space.

Angus is right. If you want to ignore the self-signed SSL then you should just use a plain http connection in the first place. If you've gone through the trouble of installing a self-signed cert on the server, you may as well add it to the client so you complete the circle. If you can't use a self-signed cert on your client devices, then use Let's Encrypt instead of self-signing.

Did someone verify that? Seems abandoned, but I don't see where Stefan said it was "shut down." I assume it was abandoned and I just continue to update the project groups for new versions of Delphi.

Delphi is already problematic when it comes to quality control. The new system is so mind-bogglingly horrible that the friction to post a new bug report is even greater than it used to be. And now we can't even vote for issues that matter to us, so Embacadero has no objective signal on what to focus on. This is not good for the future of Delphi. I knew an ISV developer who made pretty decent Windows utilities who would go out of his way to hide feedback mechanisms in his software. He would hide contact details behind a menu item only accessible from the form's system menu, so only the most determined people would ever find it. He just didn't want to deal with customers. This reminds me of that. The new QA is so irritating to use that I just don't even go there. The old one sucked bigtime, but it was at least usable enough that I would try. Now I am not even bothering.

No Clipper in my history, sorry. :-) I would recommend learning Git for source control. It can be integrated into the IDE but I don't ever use it that way -- I prefer a dedicated Git client, specifically Fork. However much time it takes you to learn to use it is time well spent. Once you train yourself to commit your changes and branch off for experiments, you will never worry about breaking your code, and problems like what you posted here are very easily solved, because you can always see everything that changed, exactly.

Probably easier just to compare your current changes to your last commit.