balabuev

By Windows I guess. If some window becomes destroyed, all its pending messages are removed from the queue. No. Unless you explicitly call Application.ProcessMessages [potentially] in a loop.

Prove it.

Can you please provide the exact class name? It's not the class of your menu component, but the class of menu item, right?

Good observation, but wrong. Setting Action to caFree effectively executes form's Release method, which posts CM_RELEASE mesage to the message queue to perform async destroying of the form later (look at VCL source code). So, since the form including its Handle is freed with an explicit Free method in the TLogInForm.Execute, the subsequent CM_RELEASE message is ignored. This can be tested by overriding the message handler: type TLogInForm = class(TForm) //... procedure CMRelease(var Message: TMessage); message CM_RELEASE; //... end; procedure TLogInForm.CMRelease(var Message: TMessage); begin ShowMessage('Ooops.'); inherited; end;

Maybe. I do not use Auto invoke mode personally. Imho, this mode requires even more key presses than manual invoke mode. But, this is another story, not related to 10.4.2. Anyway, Finish incomplete properties check box should be disabled when Auto invoke is checked. Otherwise, it's confusing. Btw, Auto invoke does not work for me in LSP mode. Probably, this was another source of confusion.

I've found the reason. Auto invoke need to be unchecked. Don't know now, whether it is my fail or Auto invoke was checked by default.

No. It's checked (in both LSP and Classic modes).

I'll try to create it today and will drop note here...

Yes. In previous IDE versions I can type the whole line like this without pressing Enter at all: Canvas.Brush.Color := clRed;

Or no, sorry. I meant another scenario: Type partial name like "Canv" Press Ctrl+Space to open drop-down list Select "Canvas" (do not press Enter, just select the item in the list with Up/Down keys) Press '.' (dot) character You should see 'Canvas.' in the editor. But I get only 'Canv.' instead.

Hmm.. I'm testing on a clear VCL project, within a simple OnCreate event handler. Trying to type Can[vas]. Nothing special. But, it good to know, that it works for you. Can someone else check it?

Even in Classic Code Insight mode IDE no longer completes the identifier when typing symbol character, like dot or open brace. 😭😭😭

With 10.5 whole cycle will repeats . So, 10.5.1 will be bugfull like hell, 10.5.2 - will look promising, 10.5.3 - slightly better.

type TFoo = TObject; TBar = TDictionary<Byte, Byte>; var a: TFoo; // Ctrl+Click here navigates to TFoo, despite it's an alias. b: TBar; // Ctrl+Click here navigates to TDictionary<> in Generics.Collections unit.

Confirmed. I can reproduce it. However in my case no stack overflow occured. IDE simply hang out (forewer) with this small popup window:

That's different delay, I do not use it.

1) I see Code Insight no more completes identifier when I type "." (dot) or any other symbol like semicolon or open round bracket in the following editor state: This seems to me as a big regression. 2) Overall, this new nonblocking code insight idea is really a pain in pactise, because I have to wait each time until drop-down window is appeared (which happens with a delay) before continue typing. In the above situation in XE2, for example, I can very quickly press Ctrl+Space and then ".", and be sure that "Canvas." will be typed. But, with async drop-down window the result depends of typing speed.

Test project (was already provided in one of previous posts)

I have to admit that this is one of rare cases when I cannot find the reason of issue What I've found: - Upon closing the form calls DestroyWindow in its destructor to destroy self handle. As specified in MSDN, DestroyWindow destroys all children windows (recursively) and then - the window itself. And it should send WM_DESTROY messages. - So, this is not Delphi stuff (no recursive itertation of children, etc) - all handles of all controls are destroyed with a single call to DestroyWindow. - However, WM_DESTROY is not received by the tree view. Moreover, WM_NCDESTROY message (which should be sent after WM_DESTROY) is received - and so, this is an indicator that everything is still set up at the moment (constrol exists; its handle exists and valid; its WndProc is still wired and continues to receive messages). So, I believe that something crazy happens recursively, which prevents DestroyWindow to do its work correctly. Maybe DestroyWindow or some other incompatible API is called second time from one of messages sent by the original DestroyWindow call - something like that. I've tried to Google, but was unable to find any results where people discuss mising WM_DESTROY messages. Another idea is that some hook (maybe even style hook) eats the message. But, unfortunately, tree view's style hook also does not receive WM_DESTROY. Who steal the message!!!

Not yet. But I see that the tree view does not receive WM_DESTROY message after pressing a close button. Which is quite strange.

Hmm, now I cannot believe also. Will try to debug. Edit: These four controls - are styled scrollbars (TScrollingStyleHook.TScrollWindow). Edit: Workaround: type TTreeViewFix = class(TComponent) private FView: TTreeView; FOldWnd: TWndMethod; protected procedure Notification(C: TComponent; O: TOperation); override; procedure WndHook(var M: TMessage); public class procedure Apply(AView: TTreeView); end; procedure TTreeViewFix.Notification(C: TComponent; O: TOperation); begin inherited; if (C = FView) and (O = opRemove) then begin FView.WindowProc := FOldWnd; Free; end; end; procedure TTreeViewFix.WndHook(var M: TMessage); begin if (M.Msg = WM_NCDESTROY) and (csDestroying in FView.ComponentState) then FView.Items.Clear; FOldWnd(M); end; class procedure TTreeViewFix.Apply(AView: TTreeView); var fx: TTreeViewFix; begin fx := TTreeViewFix.Create(nil); try fx.FView := AView; fx.FOldWnd := AView.WindowProc; AView.WindowProc := fx.WndHook; AView.FreeNotification(fx); except fx.Free; raise; end; end; procedure TMainForm.FormCreate(Sender: TObject); begin TTreeViewFix.Apply(TreeView); //... end;

Components are not destroyed on style change. Only RecreateWnd is called.

Use Explicit rebuild, not Rebuild as needed I will consider this one...

I removed as much as possible from your demo. It's now independent from SVG image list, and refers only to standard components. I removed almost all code also. Source.zip What is interesting: removing the bottom list view will stop the bug from occurring.