WM_CREATE and taskbar entry

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

WM_CREATE and taskbar entry

Max Cairns
Hi; apologies if this isn't the gcc forum. I've got a query about the task bar entry for a program compiled using gcc under Windows 10.
The standard Win 32 GUI skeleton on both CodeBlocks and DevC generates code which creates an entry in the taskbar while the program is running. However, if I add something like this:
case WM_CREATE:
    MessageBox(hwnd,"Hello","Test",MB_OK);
   break;
to the WindowProcedure, then that entry into the task bar doesn't appear until after I press OK in the message box.
The same is true if I do this:

case WM_CREATE:
  SendMessage(hwnd,WM_COMMAND,(WPARAM)1234,0);
  break;
case WM_COMMAND:
  if(LOWORD(wParam)==1234)MessageBox(hwnd,"Hello","Test",MB_OK);
  break;

and also if I put the SendMessage in WM_SHOWWINDOW rather than WM_CREATE.

This wouldn't matter much if it was just a MessageBox that was being invoked at startup, but (for me) it's often a call to a dialog procedure; and without that task bar entry I can't (for instance) un-minimise the application or bring it to the front of the screen. FWIW, I have used use this technique with the Borland IDE without issue, so I suspect it's something in gcc?
I have found a work-around - if I start a 1-sec timer in WM_CREATE, then use the WM_TIMER hit to do the SendMessage, all is well (so long you don't forget to kill the timer!). But I thought I'd ask if I'm doing something invalid.
Thanks
Max Cairns
[hidden email]

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: WM_CREATE and taskbar entry

Keith Marshall
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/06/16 10:33, Max Cairns wrote:
> Hi; apologies if this isn't the gcc forum.

Well, it isn't a forum; it's a mailing list, but its focus is on the
use of the MinGW.org distribution of GCC, for applications development
on MS-Windows.

> task bar entry for a program compiled using gcc under Windows 10.
> The standard Win 32 GUI skeleton on both CodeBlocks and DevC
> generates code which creates an entry in the taskbar while the
> program is running.

Don't be distracted by CodeBlocks, or DevC; they are irrelevant.  This
is a fundamental feature of the Windows API itself.

> However, if I add something like this:
>
> case WM_CREATE: MessageBox(hwnd,"Hello","Test",MB_OK); break;
>
> to the WindowProcedure, then that entry into the task bar doesn't
> appear until after I press OK in the message box.

First a disclaimer: my expertise lies more in console application
development, or in core API development, than in GUI applications.
That said, I think this behaviour id kind of what I would expect.
See, you are interrupting the normal (main) window creation and
display process, by a modal procedure, which requires the user to
dismiss it, before the task bar button is created, (by the
ShowWindow() call from within WinMain()).

> The same is true if I do this:
>
> case WM_CREATE: SendMessage(hwnd,WM_COMMAND,(WPARAM)1234,0);
> break; case WM_COMMAND:
> if(LOWORD(wParam)==1234)MessageBox(hwnd,"Hello","Test",MB_OK);
> break;
>
> and also if I put the SendMessage in WM_SHOWWINDOW rather than
> WM_CREATE.

Same thing here; you're introducing a modal procedure too early in the
main window initial display process.

> I have found a work-around - if I start a 1-sec timer in
> WM_CREATE, then use the WM_TIMER hit to do the SendMessage, all is
> well (so long you don't forget to kill the timer!).

Seems kludgey, and very ugly.

> But I thought I'd ask if I'm doing something invalid.

Let WinMain() complete the main window creation, and first
ShowWindow() call, then send your message to start your dialogue, just
before you start the message loop.

- --
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJXTs1FAAoJEMCtNsY0flo/XWIP/2le/uVo0lh+Y9g/2zW7BQDr
IHNaabPx0RjABwTSdmwAXKolUhj3daed8QvOJlxdAhbmKDwjpAKhgJs2rZVGqn8u
BHl8m35TXtWpjbKoS3iGYFZ22qZO/H2XyrWCpCSQZkK77OGPdOWzNk8Rr63ousF1
3e2pI6Sd1+3/VwcU2BDo9JojXSoKIHXnA7VCJWV9ctRLegNucJfEOwBnLWJ3eJFc
4SacPgi7D6Z1MlMfDQf3ij1Y5o3XepSZT2AW6CHUimh1E32dtBVLbwN5H5I3NnCT
dZaQrUsdQIiMklFes/pPzoqNMUF4bX02hNGk5CVIX2u5UGi7mOpi0mBFmzT+nnCc
P9AMHchXBSvEweMWF4IzqiwhQVezUkU69MZAAvKzxcIsfI2F0Q5fJioT/9kbXNN6
ouq+3A63KqMJ/ErrM5DGcXRj7XkSZXB4GT36OCqxkXlgMcWGiZ7qqMhMLStRE76g
iBt85SRLbgvWnXcm0uP9sh1tgm5nXEW4vxA2FEPU+CrC5wKQtAkJxLlqnYHPxc1D
4K1XGAVcS6aDw4lP2CjhLE82okNwselW0p6Tg0m7wuomHTxYhMdfqi6hdgcfMMTU
SzD+gfoWtceBnd9gWJX6X5sDWBI96BrVWNzHcTEb448KYHju9GW5PXz7JKbhcRZ5
Oup/jwqtmIrOnGYTGCPv
=3of6
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: WM_CREATE and taskbar entry

Max Cairns
Yes, that's fixed it, thanks: putting the SendMessage in WinMain just
before the message loop. Much better than that clumsy 1-second delay.

I'm a little surprised that calling SendMessage while setting up the
window didn't just add the message to the back of the message queue and
therefore not be dealt with until the initialisation was complete... but
it doesn't matter now that I've got a proper technique.

Thanks for your help.

Max


On 6/1/2016 12:55 PM, Keith Marshall wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 01/06/16 10:33, Max Cairns wrote:
>> Hi; apologies if this isn't the gcc forum.
> Well, it isn't a forum; it's a mailing list, but its focus is on the
> use of the MinGW.org distribution of GCC, for applications development
> on MS-Windows.
>
>> task bar entry for a program compiled using gcc under Windows 10.
>> The standard Win 32 GUI skeleton on both CodeBlocks and DevC
>> generates code which creates an entry in the taskbar while the
>> program is running.
> Don't be distracted by CodeBlocks, or DevC; they are irrelevant.  This
> is a fundamental feature of the Windows API itself.
>
>> However, if I add something like this:
>>
>> case WM_CREATE: MessageBox(hwnd,"Hello","Test",MB_OK); break;
>>
>> to the WindowProcedure, then that entry into the task bar doesn't
>> appear until after I press OK in the message box.
> First a disclaimer: my expertise lies more in console application
> development, or in core API development, than in GUI applications.
> That said, I think this behaviour id kind of what I would expect.
> See, you are interrupting the normal (main) window creation and
> display process, by a modal procedure, which requires the user to
> dismiss it, before the task bar button is created, (by the
> ShowWindow() call from within WinMain()).
>
>> The same is true if I do this:
>>
>> case WM_CREATE: SendMessage(hwnd,WM_COMMAND,(WPARAM)1234,0);
>> break; case WM_COMMAND:
>> if(LOWORD(wParam)==1234)MessageBox(hwnd,"Hello","Test",MB_OK);
>> break;
>>
>> and also if I put the SendMessage in WM_SHOWWINDOW rather than
>> WM_CREATE.
> Same thing here; you're introducing a modal procedure too early in the
> main window initial display process.
>
>> I have found a work-around - if I start a 1-sec timer in
>> WM_CREATE, then use the WM_TIMER hit to do the SendMessage, all is
>> well (so long you don't forget to kill the timer!).
> Seems kludgey, and very ugly.
>
>> But I thought I'd ask if I'm doing something invalid.
> Let WinMain() complete the main window creation, and first
> ShowWindow() call, then send your message to start your dialogue, just
> before you start the message loop.
>
> - --
> Regards,
> Keith.
>
> Public key available from keys.gnupg.net
> Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.20 (GNU/Linux)
>
> iQIcBAEBAgAGBQJXTs1FAAoJEMCtNsY0flo/XWIP/2le/uVo0lh+Y9g/2zW7BQDr
> IHNaabPx0RjABwTSdmwAXKolUhj3daed8QvOJlxdAhbmKDwjpAKhgJs2rZVGqn8u
> BHl8m35TXtWpjbKoS3iGYFZ22qZO/H2XyrWCpCSQZkK77OGPdOWzNk8Rr63ousF1
> 3e2pI6Sd1+3/VwcU2BDo9JojXSoKIHXnA7VCJWV9ctRLegNucJfEOwBnLWJ3eJFc
> 4SacPgi7D6Z1MlMfDQf3ij1Y5o3XepSZT2AW6CHUimh1E32dtBVLbwN5H5I3NnCT
> dZaQrUsdQIiMklFes/pPzoqNMUF4bX02hNGk5CVIX2u5UGi7mOpi0mBFmzT+nnCc
> P9AMHchXBSvEweMWF4IzqiwhQVezUkU69MZAAvKzxcIsfI2F0Q5fJioT/9kbXNN6
> ouq+3A63KqMJ/ErrM5DGcXRj7XkSZXB4GT36OCqxkXlgMcWGiZ7qqMhMLStRE76g
> iBt85SRLbgvWnXcm0uP9sh1tgm5nXEW4vxA2FEPU+CrC5wKQtAkJxLlqnYHPxc1D
> 4K1XGAVcS6aDw4lP2CjhLE82okNwselW0p6Tg0m7wuomHTxYhMdfqi6hdgcfMMTU
> SzD+gfoWtceBnd9gWJX6X5sDWBI96BrVWNzHcTEb448KYHju9GW5PXz7JKbhcRZ5
> Oup/jwqtmIrOnGYTGCPv
> =3of6
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:[hidden email]?subject=unsubscribe
>


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe