Board index » delphi » Taskbar buttons for child windows

Taskbar buttons for child windows

Hi all,

I have an application that started life under Delphi 3 and was later
migrated to Delphi 5. Until recently, opening a dialog for any sub-process
would create a separate button on the taskbar and, in the context of our
application, this was desirable behavior. Recently some outdated code was
retired and somehow the process of removing those items from the project
(or references that they contained) resulted in our entire application
being reduced to a single taskbar button. In addition, this button now
seems to point to the TApplication window rather than my main form as it
did previously.

From my research it appears that this multiple taskbar-button behavior was
a "bug" that was corrected in Delphi 4 (unfortunately, I lost track of the
reference that told me this) but we would really like to restore the
original behavior. Unfortunately, since I don't know exactly what changed
or why, I have no idea how to go about doing that. I've tracked down
several tips that suggested changing the parent of my main form to point to
the Windows desktop and adding the WS_EX_APPWINDOW extended window style,
but that really only takes care of the main form itself. Whatever changed
the application's behavior occurred at the project level and did not
involve any changes to the code that creates and displays the child
windows.

I should probably mention that the top-level window for each sub-process is
a non-modal dialog that is created dynamically at runtime with MainForm as
the owner. In addition, the project changes I made also resulted in
InfoPower 2000 being removed from active use in my application. I don't
know if InfoPower would have any way of influencing the handling of these
windows but I'm hoping that someone here can help me differentiate between
this being a Delphi issue or an InfoPower issue.

Thanks for any suggestions you can offer.

Regards,
Creed Lilly
NECS, Inc.

 

Re:Taskbar buttons for child windows


In article <Xns92C4A28F469Dxcelillyxxnecsx...@207.105.83.65>, Creed Lilly
wrote:

Quote
> I have an application that started life under Delphi 3 and was later
> migrated to Delphi 5. Until recently, opening a dialog for any sub-process
> would create a separate button on the taskbar and, in the context of our
> application, this was desirable behavior.

But it is not the default behaviour of a Delphi application.

Quote
> Recently some outdated code was
> retired and somehow the process of removing those items from the project
> (or references that they contained) resulted in our entire application
> being reduced to a single taskbar button. In addition, this button now
> seems to point to the TApplication window rather than my main form as it
> did previously.

And that *is* the default behaviour of a Delphi application. To get the old
behaviour back requires some surgery, i'm afraid.

In the main forms FormCreate do this

  ShowWindow( Application.handle, SW_HIDE );
  SetWindowLong( Application.handle,
                 GWL_EXSTYLE,
                 GetWindowLong( application.handle, GWL_EXSTYLE ) and
                   not WS_EX_APPWINDOW or WS_EX_TOOLWINDOW);
  ShowWindow( Application.handle, SW_SHOW );

That removes the application button from the taskbar.

The main form gets a handler for the WM_SYSCOMMAND message:

  private // form declaration
    Procedure WMSyscommand(Var msg: TWmSysCommand);
      message WM_SYSCOMMAND;

Procedure TForm1.WMSyscommand(Var msg: TWmSysCommand);
  Begin
    Case (msg.cmdtype and $FFF0) of
      SC_MINIMIZE: Begin
          ShowWindow( handle, SW_MINIMIZE );
          msg.result := 0;
        End;  
      SC_RESTORE: Begin
          ShowWindow( handle, SW_RESTORE )
          msg.result := 0;
        End;  
      Else
        inherited;
    End;
  End;

This disables the default minimization behaviour.

To get a task bar button for the form and have it minimize to the taskbar
instead of to the desktop, override the CreateParams method of the main form
and also of all the secondary forms:

    // in form declaration
    Procedure CreateParams( Var params: TCreateParams ); override;

Procedure TForm1.CreateParams( Var params: TCreateParams );
begin
  inherited CreateParams( params );
  params.ExStyle := params.ExStyle  or WS_EX_APPWINDOW;
end;

--
Peter Below (TeamB)  
Use the newsgroup archives :
http://www.mers.com/searchsite.html
http://www.tamaracka.com/search.htm
http://groups.google.com
http://www.prolix.be

Re:Taskbar buttons for child windows


In article <Xns92C67A7FED316xcelillyxxnecsx...@207.105.83.65>, Creed Lilly
wrote:

Quote
> Thanks for the info. I have not yet tried making such extensive changes as
> those you describe but it sounds like the extra steps will probably take
> care of some of the remaining issues I had with earlier experiments. I
> guess I was just hoping that there was some kind of "magic bullet" that
> would restore the application's original behavior. The most frustrating
> aspect of the whole situation is that I can take an archived copy of an
> older version of the app, build it in my current D5 environment and it will
> have the multi-button behavior without any of the code changes that you
> describe.

Then i suspect that one of the 3rd-party components you removed from the D7
version was responsible for the behaviour.

--
Peter Below (TeamB)  
Use the newsgroup archives :
http://www.mers.com/searchsite.html
http://www.tamaracka.com/search.htm
http://groups.google.com
http://www.prolix.be

Re:Taskbar buttons for child windows


Hi Peter,

Thanks for the info. I have not yet tried making such extensive changes as
those you describe but it sounds like the extra steps will probably take
care of some of the remaining issues I had with earlier experiments. I
guess I was just hoping that there was some kind of "magic bullet" that
would restore the application's original behavior. The most frustrating
aspect of the whole situation is that I can take an archived copy of an
older version of the app, build it in my current D5 environment and it will
have the multi-button behavior without any of the code changes that you
describe. If the application had never worked this way in the past I
probably would never have given it a second thought. But the application
has been in release for over two years now and we, and our users, have
grown accustomed to the multi-button behavior. I don't suppose that there
is any way of overriding the form-creation process at the application
level, is there? On the other hand, if we successfully implement these
changes now then I shouldn't have to worry about problems when we upgrade
this app to D7 sometime next year.

Well, thanks again for your input and if you happen to think of any other
possible solutions then I'd be happy to hear them.

Regards,
Creed Lilly
NECS, Inc.

"Peter Below (TeamB)" <100113.1...@compuXXserve.com> wrote in
news:VA.000095e8.00672fb7@antispam.compuserve.com:

Quote
> In article <Xns92C4A28F469Dxcelillyxxnecsx...@207.105.83.65>, Creed
> Lilly wrote:
>> I have an application that started life under Delphi 3 and was later
>> migrated to Delphi 5. Until recently, opening a dialog for any
>> sub-process would create a separate button on the taskbar and, in the
>> context of our application, this was desirable behavior.

> But it is not the default behaviour of a Delphi application.

>> Recently some outdated code was
>> retired and somehow the process of removing those items from the
>> project (or references that they contained) resulted in our entire
>> application being reduced to a single taskbar button. In addition,
>> this button now seems to point to the TApplication window rather than
>> my main form as it did previously.

> And that *is* the default behaviour of a Delphi application. To get
> the old behaviour back requires some surgery, i'm afraid.

> <--- code samples removed --->

> --
> Peter Below (TeamB)  
> Use the newsgroup archives :
> http://www.mers.com/searchsite.html
> http://www.tamaracka.com/search.htm
> http://groups.google.com
> http://www.prolix.be

Re:Taskbar buttons for child windows


That's been a suspicion of mine since this first happened but I wasn't
sure. I was split between that and the possibility that the changes I made
to the project had triggered some internal property of the project to be
changed, reset or whatever. The module that I retired was mainly using some
InfoPower data-aware components so, if their presence (or absence) was the
cause of the change in the program's behavior, then I was hoping that
someone here may have encountered a situation where their program was
"broken" by the addition of these components. I did a quick experiment
yesterday to just throw a couple of those components on a form so that
InfoPower would be linked back into the application but it didn't seem to
make a difference. However it was just a quick experiment and I want to do
a more thorough test before I say that it absolutely doesn't make a
difference.

On a brighter note, however, those code changes that you suggested worked
very well. So, unless we find that "magic bullet", at least I have an
alternative.

Many thanks for your help!

Regards,
Creed Lilly
NECS, Inc.

"Peter Below (TeamB)" <100113.1...@compuXXserve.com> wrote in
news:VA.000095ee.0068c51b@antispam.compuserve.com:

Quote
> Then i suspect that one of the 3rd-party components you removed from
> the D7 version was responsible for the behaviour.

> --
> Peter Below (TeamB)  
> Use the newsgroup archives :
> http://www.mers.com/searchsite.html
> http://www.tamaracka.com/search.htm
> http://groups.google.com
> http://www.prolix.be

--
Creed Lilly <xcelil...@xnecsx.com>
remove 'x' to reply by E-mail

Other Threads