Hello Lazarus-List,

Does anybody know the technical reason why the application handle can not be the mainform handle ?

Both Delphi and LCL/Win32 uses this approach, one zero-size window that is shown in the taskbar and all the forms are non taskbar buttons (unless forced to have one). I have a lot of curiosity about this topic, maybe different events for application and each form ?

This difference with regular windows programs create some strage behaviors like non preview in vista/7 taskbar when minimized, no window animations (simulated by LCL, but non working in composite desktops), excessive use of SetWindowPos, etc.

Thank you.

Jos? Mejuto wrote

Does anybody know the technical reason why the application handle can not be the mainform handle ?

1. Application must have only 1 icon on the taskbar
2. Forms need to have the same z-order (non-main forms should not be always on top of the main form)
3. All application windows needs to be minimized/restored on taskbar item mimizise/restore

All this caused the decision to add a dummy application window which is a parent of all the forms.

It is possible to implement all this without that window but:
1. some things will be more difficult
2. some user code can depend on Application.Handle

Somewhere in the future we will reimplement this.

Best regards,
Paul Ishenin.

Hello Lazarus-List,

Friday, May 7, 2010, 1:15:38 AM, you wrote:

PI> 1. Application must have only 1 icon on the taskbar

And it should not be the mainform one ? In other words would it be acceptable that the taskbar icon and caption is the mainform caption instead the Application one ?

PI> 2. Forms need to have the same z-order (non-main forms should not be PI> always on top of the main form)

Hmmmm... this could be a problem, yes.

PI> 3. All application windows needs to be minimized/restored on taskbar PI> item mimizise/restore

All forms must follow the Application.handle state, so once mainform minimized, all other forms must follow. I see.

PI> All this caused the decision to add a dummy application window which is PI> a parent of all the forms.
PI> It is possible to implement all this without that window but: PI> 1. some things will be more difficult
PI> 2. some user code can depend on Application.Handle PI> Somewhere in the future we will reimplement this.

Do you think that if me of any other solves some of this problems (some could be impossible due the application.handle and mainform.handle equality) at least the possible patch would be taken in evaluation ? I'm asking because if it is against design it will be never applied in any way.

IMO it's a bad idea to minimize forms together with the main form. Better the application should minimize, automatically hiding all owned forms.

The placement of minimized forms varies across window managers. Win32 (or Delphi?) puts them onto the bottom of the screen, so that every window can be restored from there. This behaviour may be related to the implementation of MDI windows, where minimized MDI childs reside on the bottom of the MDI window. Other window managers require a window menu to restore minimized form. In no case forms should become part of the task bar, this one is reserved for tasks (applications) - as the name says.

DoDi

Hello Lazarus-List,

you wrote

> PI> 3. All application windows needs to be minimized/restored on taskbar > PI> item mimizise/restore > All forms must follow the Application.handle state, so once mainform > minimized, all other forms must follow. I see.

HPD> IMO it's a bad idea to minimize forms together with the main form. HPD> Better the application should minimize, automatically hiding all owned HPD> forms.

I wrote "others must follow" in the sense of the others must react in the currently defined way, this means the current behavior or better the expected behavior taking in account the ShowInTaskBar flag and the window style.