balabuev

If we speak about combo-box like controls - yes it matters. The user percept main form de-activating/re-activating like flickering, like unwanted behavior.

Yes, something like this. But what is interesting, why Windows does not allow to achieve this natively, without cheating.

I noted previously - the question is theoretical. I understand how native combo-box works, and how it prevents its own drop-down window from having real focus - and so, such case is not interesting. If you want some example, imagine TMemo inside the popup. It requires real focus not only to process key events, but also, because it hides the caret in non-focused state. And there more minor differences. But, anyway, tweaking the control and redirecting events - is not a part of my question.

When TolWindow or some of its children got the focus, the main window will be de-activated. This is exactly the problem.

I cannot understand how this relates to my question? And what is special about bsToolWindow border style (WS_EX_TOOLWINDOW in WinAPI terms)?

Yes, the question can be re-formulated like this.

To clarify things: No. I'm speaking about native Windows API, and thats why I've chosen Windows API forum section. Relative to Delphi I'm more speaking about some custom combo-box like control, in which the popup window may be a descendant from TCustomControl with overridden CreateParams, ect. Yes. Which means that: Winapi.Windows.GetFocus = MyPopupWindow.Handle // Popup window has real focus No. Its impossible for two windows have focus simultaneously (I'm not so stupid ). I want main window (or main form - no big difference here) to remains active: Winapi.Windows.GetActiveWindow = MainWindow.Handle However, if there no native Windows way to achieve this, the next question - what is a canonical way to "simulate"? I guess I'll need to hook main window (control's parent form) WndProc and suppress some non-client area related messages...

This is a theoretical question, not related to any particular problem. I think similarly, but asked here to ensure that I'm not mising something. Some combination of window styles, things like that...

I guess the real reason, why Delphi represents components in packages as string names (as opposed to direct TClass references) is because a package can stay in non-loaded state. Look at IOTAPackageInfo.Loaded property.

Collections as records seems to me a good idea. I've thinked about creation of such a library for a long time. However, my goals was to achieve as light solution as possible. For example, every TList instance currently - are several heap memory blocks. Two objects and a block of memory for items. Every object in Delphi have implicit try/except in its constructor, and so on.... So, Tlist is quite more complicated compare to native dynamic arrays (which seems to me much more optimal). Also, I think value sematics of record types should be supported. So, when A and B are collections, user can assign one to another, like A := B. And here something like copy-on-write should be provided. For this either: Delphi 10.4 managed records feature can be used, or, collection types should have single interface field (IInterface or similar), and all requited additional data fields (like Count, Capacity, ect. fields) should be incapsulated into it. This complicate things to some degree. Also, this way (with a single interface field inside) collections, implemented as record types, wil be able to auto-initialize and auto-free itself, which will simplify user's code.

My vote is for this way: On the orther hand, collections are different from arrays in the following aspect: colections are typically used in much wider scopes (like in public APIs) than arrays (which are mostly used quite locally).

I think you misunderstood the initial task...

Everything works ok. You have to use Math and StrUtils units.

procedure CombineMemos(const AMemos: array of TMemo; ADelimiter: Char; AResult: TMemo); var i, cnt: Integer; rem: UInt64; idx: UInt64; mm: TMemo; s: string; begin cnt := Ord(Length(AMemos) > 0); for mm in AMemos do cnt := cnt * mm.Lines.Count; for i := 0 to cnt - 1 do begin s := ''; rem := i; for mm in AMemos do begin DivMod(rem, mm.Lines.Count, rem, idx); s := s + IfThen(mm <> AMemos[0], ADelimiter, '') + mm.Lines[idx]; end; AResult.Lines.Add(s); end; end;