balabuev

I have another one (more exotic) example: unit Unit1; interface type TFoo = record X: set of (s1, s2, s3); Y: record Z: (e1, e2, e3); end; end; TBar = class private procedure P; // Ctrl+Shift+C does not work! end; implementation end.

Slow...

It can be done much simpler: 1) Use FindRootDesigner function defined in Classes.pas. 2) Just cast the return value to IDesigner. dsnr := FindRootDesigner(AComponent) as IDesigner;

New LSP is unusable, and even old Code Insight is broken! New bugs in code editor were introduced. And they call 10.4.1 release - a quality release (WTF?)!

I have the same issue. I've reported the bug, but (as always) see no reaction from Embarcadero: https://quality.embarcadero.com/browse/RSP-31823

Whether it theoretically possible in Windows to have a popup window with some focused control (child window) in it, while keeping application's main window active?

I see nothing interesting in your code. You still not even trying to explain what exactly you want to show? At least, how this code should be used step by step, and what should we see as a result? Just for fun: attach zipped sources.

So, returning to the idea, I've formulated for you: 1) The user sees "focused" opened drop-down window. 2) And the main form is "active" at the same time. And, this violates following your proposal:

1) I did not said "edit". I've said - press Up/Down arrow keys to change selected item. 2) I did not said "in combo box". Instead I've said - in currently opened drop-down. That's a big difference in logic.

Combo box drop-down window is not a pure "viewport". The user can actively interact with it using mouse (which is outside of the discussed topic) and keyboard. So, the user can press Up/Down arrow keys to change selected item in opened drop-down. So, from the user perspective (*) drop-down window is focused. Even in simple standard combo box. (*) User - means simple user, not technically educated. For him, the concept of focus is - simply the area, which reacts to key presses.

Still understand nothing. What is "viewer"?

Can you be more descriptive? I cannot understand what you want to say?..

Agree. I'm always use "const" modifier before any parameter of managed type (arrays, strings, interfaces, references to procedure types) or of big record type, because it executes faster. I remeber one or two such issues, which, by the way, was quite hard to debug, but, imho, this is still not the reason to remove all "const" parameter modifiers.

Using a timer and two edits on a form I've created small tool (which is not full featured "spy", of course): procedure TForm11.Timer1Timer(Sender: TObject); var awn: HWND; buf: array[0..1024] of Char; begin awn := GetForegroundWindow; if awn <> 0 then begin GetClassName(awn, @buf, Length(buf)); Edit1.Text := buf; end else Edit1.Text := ''; Edit2.Text := IntToHex(awn, 8); end; So, clicking on different forms in Photoshop gives the following results: 1) "Photoshop". 2) "OWL.Dock". So, the conclusion: active window is changed to follow real focus, and so, main form just "simulates" its pseudo-active state. I've also checked Paint.NET - same results.

Photoshop also have such behavior: Photoshop does not respect theme colors, but this is not big deal. I'm sure that Paint.NET (just like Photoshop) - are just a custom drawn non-client area of the main form. Which is fine - this seems to be the closest possible solution. And - good idea about "spy" tool to realize what really happens. I thought about it yesterday too... Also, I want to duplicate my simple code, cause it was hidden by other messages. It allows to keep impression that the form is always "active", even if the user clicked on another form or application. So, this way can be used to "simulate" what I need: type TForm1 = class(TForm) private procedure WMNCActivate(var Message: TWMNCActivate); message WM_NCACTIVATE; end; var Form1: TForm1; implementation {$R *.dfm} procedure TForm1.WMNCActivate(var Message: TWMNCActivate); begin Message.Active := True; inherited; end; The code works even with standard forms, without the need to custom draw form's non-client area. Also, system shadow around the form, which is slightly different in active and non-active states, is respected.

This is more a technical discussion. Every idea can be potentially used to confuse the user. So, the original question is simple: whether it is possible or not. However, if you trying to speak about conceptual side, can you explain, why native Windows combo-box control violates this "best" way (as I already noted in one of previous messages). As well, as popup menu.

All your messages in this topic are completely unrelated to what I'm speaking about, sorry...

Unfortunately, this is not related to my initial question at all.

And what should we see?

So, what is about standard combo-box with opened drop-down. You can use arrow keys to go up and down between items, while keeping main (parent) form active. I know how this is done technically, but don't you think, that conceptually this case violates your "only one window is in focus" idea?

Can you read my initial question just to understand what is all about...

That is exactly the problem.

You create a child form (or frame), not popup. Child window can't exceed the bounds of its parent window.

Yes. Btw, always "active" form is simple to cheat: type TForm1 = class(TForm) private procedure WMNCActivate(var Message: TWMNCActivate); message WM_NCACTIVATE; end; var Form1: TForm1; implementation {$R *.dfm} procedure TForm1.WMNCActivate(var Message: TWMNCActivate); begin Message.Active := True; inherited; end;

I appeciate your attempts to hack the world, but this is just not my goal .