balabuev

2 minutes ago, Lars Fosdal said:

Would it be possible to deny the focus event somehow?

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.

5 minutes ago, Lars Fosdal said:

What about the ToolWindow window style on the popup?

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

On 1/2/2021 at 1:37 AM, David Heffernan said:

Is your question, "is it possible to change the focus without changing the active window?"

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

To clarify things:

On 12/30/2020 at 10:50 AM, FPiette said:

You create a popup window as a TForm and show it non modal (that is just call Show)

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.

On 12/30/2020 at 10:50 AM, FPiette said:

Then the popup window get's the focus

Yes. Which means that:

Winapi.Windows.GetFocus = MyPopupWindow.Handle // Popup window has real focus

On 12/30/2020 at 10:50 AM, FPiette said:

Now you want to main (parent) window keep the 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...

2 hours ago, FPiette said:

you talked about a solution, not a problem.

This is a theoretical question, not related to any particular problem.

2 hours ago, Fr0sT.Brutal said:

Generally, no AFAIK.

I think similarly, but asked here to ensure that I'm not mising something. Some combination of window styles, things like that...

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 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 10/16/2020 at 8:04 PM, Stefan Glienke said:

make the range checking for index and count parameters in collection classes to depend on {$IFOPT R+}

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

On 10/19/2020 at 5:38 AM, David Schwartz said:

Write a method that creates a list of strings in an output TMemo composed of all possible combinations of lines from each of the four TMemos left-to-right (1+2+3+4) with the "delimiter" inserted between each one.

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;