Anders Melander

Just like GPS navigation systems made people forget how to find direction, apparently AI has made people forget how to think for themselves 🤔 From where do you think the about box gets its version number information?.

It should have been hidden for Delphi. Having it visible but but disabled, with no way to make it enabled, is just confusing; Poor UI design. https://learn.microsoft.com/en-us/windows/win32/uxguide/win-dialog-box#disabling-or-removing-controls-vs-giving-error-messages

That's nice. If I send you this 800.000 line legacy project I need to clean up, when can you have it ready for me? 🙂 It was written by someone who apparently had a sporadically stuck shift key, didn't like white space, and couldn't make up his mind if 1, 2, 3, or 8 space indents were the way to go.

Apart from the AI stuff, you do know how to determine the IDE version and build number, right?

A bit of Googling tells me that the purpose of the certificate is to enable it to scan encrypted HTTPS traffic.

Is that a problem? If so, why?

Nah. Although I have no love for Russia, I have no beef with Kaspersky (and these days I trust the US just as little) and I've found that it's the one that works best for me. I'm using the free version, FWIW.

Well, I got this one during install so I'm already a little bit "excited"... https://threats.kaspersky.com/en/threat/Trojan.Win32.Lazzzy.gen/

But at least you can not satisfy someone every time.

There are so many bugs and limitations in TListView (the Windows control, not the VCL wrapper) that I have found that as soon as I spend more than 10 minutes trying to work around something in it, it's often a better idea to replace it with something else. Just yesterday I needed the first column in a listview right-aligned; Forgetaboutit - and out it went.

Delphi 11

As I said, I haven't timed it - and it depends. MUL is dirt cheap. DIV is a little more expensive but not nearly as bad as it once was. Branches are almost always bad but if OldDPI=NewDPI most of the time then the jump out is obviously worth it. I honestly wouldn't bother doing this in asm in the first place. Unless you are using it to scale graphics in real-time, or something like that, then it's a completely wasted effort. Also remember that pascal code can be inlined (avoiding the call overhead), while asm functions can't. I would replace the MulDiv with a simple expression; You likely don't need the 64-bit and overflow handling baked into MulDiv (which is a Windows API function, btw - not cheap).

That's not a fork... Never mind. Not my problem.

Exactly

Yes

They will be unemployed because they know how to write code on their own? Yes, that makes perfect sense; Nobody wants to hire that kind of developers.

Without having timed this my guess is that your assembler version would be faster if you simply got rid of all the "optimizations" and just did the IMUL+IDIV. Also, newer versions of Delphi already have all this stuff in TControl.

The main question here should be: What problem does this solve? If the answer is "I once lost the options" then there is no problem - because the solution to that problem is "Don't lose the options". I'm afraid I can't see the use case.

No. Use the existing mechanisms instead (e.g. include files). It adds complexity and I'd prefer they use their limited resources on solving problems that we can't solve ourselves.

It sounds like you're about to reinvent [shudder] ActiveX.

A TPageControl is just a tab control with each page represented by a TTabSheet. If you look at the source of TPageControl.ChangeActivePage you can see that it sets Visible=True for the active page and Visible=False for the page being deactivated (if any). Since you can't paint a control that has Visible=False my guess is that what you are trying to do isn't possible without some really nasty hacks. What I think might be possible is to block repaints of the page control (LockWindowUpdate etc.), make each tab visible directly (via TTabSheet.Visible), paint them to a bitmap, restore everything, and resume repaint - or some variation of this.

Good discussions are worth repeating 🙂

Robust? It seems to me that the current implementation is pretty robust. Just because it doesn't do or behave as you'd like doesn't make it wrong; It's an age-old utility class that has to conform to a certain contract in order to not break a gazzilion applications. Regardless, it should be pretty easy to implement a helper that hacks access to the TStringList.FList array and then simply manipulate that array directly. Or you could just copy the TStringList source and modify it to your liking.

There seems to be a misunderstanding of the relationship between transactions and cursors here - or maybe I just haven't understood your description. Anyway, a server-size cursor is only valid within the transaction in which is was created. A client-side cursor is just a row pointer into a client-side rowset and does not need a transaction. I believe we are talking about server-size cursors here. For an auto-transaction, the transaction will remain active while the cursor is active. So until you have fetched all rows, or closed the query, the transaction must remain active. You can't fetch some rows from a query, close the transaction, start a new transaction, and then continue fetching rows from the query. Firebird (and Interbase) supports multiple transactions per connection so what you are doing should be possible. However, it sounds as if you are using implicit transactions which, as far as I know, will result in all implicit transactions sharing a single transaction. What you should do is either use explicit transactions everywhere, or use implicit transactions when fetching data, but explicit when updating. This will isolate your updates from whatever goes on with the select queries. Of course you'll need to have some sort of synchronization in case the two parts operate on the same rows.

The problem isn't the lookup into the hash table. The problem is that you would need to scan the whole input string in order to compute the hash key for the lookup. Again: There are many different algorithms specifically designed to efficiently search a static set of "strings" and hashing isn't one of them. Yes, of course it is.