balabuev

11 minutes ago, Lajos Juhász said:

Sometimes it can result an Access Violation, it will cause no problem if in the meanwhile the handle is not used otherwise you cannot predict the result.

Prove it.

17 hours ago, rudy999 said:

I get the message 'xx' component not found

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

1 hour ago, FPiette said:

You are freeing twice the form: Once from the OnClose because you use caFree caFree, and once when you call Free in the finally block. The second call will crash.

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;

26 minutes ago, pyscripter said:

This makes sense.

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.

2 minutes ago, pyscripter said:

Could it be that you have unchecked the "Finish incomplete properties"

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

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

6 minutes ago, Lars Fosdal said:

So, [dot] used to double as [enter] before?

Yes. In previous IDE versions I can type the whole line like this without pressing Enter at all:

Canvas.Brush.Color := clRed;

18 minutes ago, Lars Fosdal said:

I did some random spot checks in our code, and typing partial variable name[ctrl+space] or variable[dot] produces a selection very quickly.

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.

10 minutes ago, Lars Fosdal said:

It seems likely that there are certain code patterns preventing this.

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. 😭😭😭

10 minutes ago, Mike Torrettinni said:

10.4.2. looked so promising at the beginning, seems like I will wait for 10.5.

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.

6 minutes ago, David Heffernan said:

You have not defined a type there. You've defined an alias. That's a crucial distinction that is very relevant for the behaviour you observe.

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.

8 hours ago, FredS said:

This is unbelievable, can someone verify that these steps are reproducible?

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

5 minutes ago, Attila Kovacs said:

There was a setting for the delay AFAIR, isn't it?

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.

20 minutes ago, emailx45 said:

maybe if he can upload the files envolved as original for test?

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.

9 hours ago, Attila Kovacs said:

destructor TWinControl.Destroy;

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...

48 minutes ago, pyscripter said:

SVGIconImageList/Demo at master · EtheaDev/SVGIconImageList (github.com) is not a bad starting point for debugging.

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.

1 minute ago, pyscripter said:

the application was compiled with the Windows default style and the error occurs when you change the style at runtime.   I think that may be significant because it causes the controls to be recreated.

Tried this already, no luck. Btw, TTreeView with handle re-creation was always strange...