Note For the rest of this answer, the terminology used uses the meaning used by the Windows documentation . This is different from the meaning of the same term in VCL.
What happens is that your job list window is a top-level window.
Ownership places several restrictions on the window.
- A native window is always located above its owner in z-order.
- The system automatically destroys the owned window when its owner is destroyed.
- The own window is hidden when its owner is minimized.
If you want the window of your task list to be under the main window in z-order, it cannot belong to the main window. You can achieve this as follows:
class TJobListForm = class(...) protected procedure CreateParams(var Params: TCreateParams); override; ... procedure TJobListForm.CreateParams(var Params: TCreateParams); begin inherited; Params.WndParent := Application.Handle; end;
This makes the task list window a top-level window located in a hidden application window. Or alternatively:
procedure TJobListForm.CreateParams(var Params: TCreateParams); begin inherited; Params.WndParent := 0; end;
This makes the job list window an unoccupied top-level window. So now he gets a taskbar button.
Such changes will have far-reaching consequences for your application. The second and third bullet points in the list above are obvious consequences. The behavior of your windows while minimizing and their interaction with the taskbar will also be affected. I just scratched the surface. You will probably find that turning the window of your task list into the main window does not affect your program. You will find that Windows does a lot of work behind the scenes for the window owned. You may need to reproduce some of these works if you go to an unoccupied window.
source share