Anders Melander

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.

And how is that going for us? There are many, many ways of searching for occurrence of a string in a static set of strings, but hashing certainly isn't the fastest. Hashing is a generic algorithm that doesn't take strings' unique properties into account. A chatbot couldn't have expressed it better - whatever it is.

Yes, you're probably right.

Run the 32-bit executable in the debugger while specifying the 64-bit application as the host?

At the moment, as far as I've been able to conclude from what you've written, the only lead you have, to the cause of the problem, is the OnExit pattern. If I were you, I would run with that and try to eliminate that pattern everywhere (because it's a bug in user code) it occurs. That can't be too hard; Either just search for OnExit/OnEnter and examine the handler code, or place a breakpoint in SetFocus and look for recursion. The recursion is likely what breaks the focus state. Good luck.

That must mean that Windows' internal focus state has become messed up because Focused is implemented as: function TWinControl.Focused: Boolean; begin Result := (WindowHandle <> 0) and (GetFocus = WindowHandle); end; My guess is that Windows' internal SetFocus is implemented something like this: function WinApi.SetFocus(ANewFocusHandle: THandle): THandle; begin Result := FCurrentFocusHandle; if (FCurrentFocusHandle = ANewFocusHandle) then exit; if (FCurrentFocusHandle <> 0) then SendMessage(FCurrentFocusHandle, WM_KILLFOCUS, ANewFocusHandle, 0); // WM_SETFOCUS propagates to OnExit in Delphi SendMessage(ANewFocusHandle, WM_SETFOCUS, FCurrentFocusHandle, 0); // Update the internal focus state FCurrentFocusHandle := ANewFocusHandle; end; In Delphi, the WM_SETFOCUS message causes the OnExit event of the currently active control to fire. If you, in the OnExit handler then does something that causes the focus to change (e.g. activating another form) then the internal focus state will become invalid. So again, I suggest you focus your efforts on fixing the problem instead of working around it - large code or not.

GetFocus & SetFocus if (MyEdit.Handle <> GetFocus) then SetFocus(MyEdit.Handle); or simply if (not MyEdit.Focused) then MyEdit.SetFocus; You have all this info available in the VCL source and the Windows API. ...but why not simply avoid doing the thing that causes the problem in the first place?

It hasn't "lost" the caret. It just doesn't have focus - hence no caret.

I think Microsoft has a whole division dedicated to coming up with ways to make the Start menu shittier for each new version of Windows. Windows 8 is still the champion though - Like that other version 8 which is best forgotten.

One of the benefits of a pull request is to make it as easy as possible for the maintainer, who probably has better things to do than manually comparing files to find differences, to review, comment on, and merge changes. Posting the modified file somewhere doesn't do that.

You can't. The "global" solution to doing something that causes problems is to stop doing something that causes problems.

You mean the caret, right? The cursor is the one you move with the mouse. The caret is the blinking indicator that shows the current position in a text control. The caret should be shown automatically if an edit control has the focus (unless it's been explicitly hidden with HideCaret (it's hasn't in this case)) so my guess is that the sequence of actions you are doing (see Peter's answer) is causing VCL to think that the control has focus while Windows is of another opinion (and of course Windows is always right, in this case). One solution would be to simply not lose the focus by showing your fading form without activating it. See ShowWindow(SW_SHOWNA). Another is the PostMessage trick Peter mentioned. I wouldn't recommend the TTimer workaround - it's a lazy hack. const MSG_DO_STUFF = WM_USER; type TMyForm = class(TForm) private procedure MsgMyStuff(var Msg: TMessage); message MSG_DO_STUFF; end; ... procedure TMyForm.MsgMyStuff(var Msg: TMessage); begin ShowDialog('It works!'); end; procedure TMyForm.Edit1Exit(Sender: TObject); begin PostMessage(Handle, MSG_DO_STUFF, 0, 0); end;

Maybe this would be a good occasion to learn Git then... Here's a quick intro I made for someone else that wanted to contribute a change to Graphics32: On Github Create a Github account: https://github.com/signup Fork the Graphics32 repository to your own Github account. This gives you a copy, on your own Github account, of the main repository where you can push your changes. On your local system Clone your own Graphics32 repository to your local system using a Git client. I recommend the Fork git client: https://git-fork.com/ Create a branch in your local repository. Commit your changes to that branch. Push the branch to your own Graphics32 repository. On Github Create a pull request on your Graphics32 repository. Specify the master branch at the main Graphics32 repository as the target, and your branch at your repository as the source. When Github notifies me that you have submitted a pull request I'll review the changes. Once I accept the pull request, the changes are merged into the branch you specified as the target branch.

...unless you also monitor the parent directory. Maybe make the polling optional?