Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Taskbar Woes 1

Status
Not open for further replies.

Zyrenthian

Programmer
Mar 30, 2001
1,440
US
Hi All,
I am running into a small problem. The product I am working on runs on single as well as dual monitors. On a single monitor system the taskbar behaves as expected.

Here is what the app should do

When it loads, it overlaps the taskbar. The user may access the task bar by pressing the "windows" key. At that time they may click on any of the apps showing in the task bar and bring them to the front.

With dual monitors, however, the taskbar is on top. I figured this would be an easy fix and I thought I had it. Here is what I did:

CWnd* pWnd;


// this gets me the taskbar
pWnd = m_pScreenDialog0->FindWindow("Shell_TrayWnd",0);

// here i adjust the z-order of the taskbar
pWnd->SetWindowPos(&CWnd::wndNoTopMost ,0,0,0,0,
SWP_NOSIZE | SWP_NOMOVE | SWP_NOACTIVATE);

// The flags in SetWindowPos have been tried in all
// possible combinations and still no luck


...

Further down in the code I have 2 CWnd poiters:

m_pScreenDialog0
m_pScreenDialog1

with these I do a SetWindowPos(&CWnd::wndTopMost,...)

The program runs and viola... my app is above the taskbar. The problem comes in when I press the windows key to bring the taskbar back to the front. It appears fine BUT clicking on any of the other apps in the taskbar does nothing. The taskbar just disappears leaving me with my app on top again. It is like the mouse click does not register. However... if I go to Programs->Apps->Something, the taskbar retains it's focus and I can then click on something in it. This is puzzling me and I dont know how to get the taskbar to behave as I want it.

I have also gone the route of using ModifyStlye and ModifyStlyeEx and those seem to produce NO results at all leaving the taskbar above my application.

If anyone has any idea on how to allow the taskbar to retain its functionality when it is no longer the top most window please help!

As for other questions... Always on Top on the taskbar is enabled and I have no way of preventing the end user from making this choice. The above functionality does work with this option selected so I dont think that is the problem.

Thanx for any help/suggestions

matt


 
> It appears fine BUT clicking on any of the other
> apps in the taskbar does nothing.

Hm... no, I don't think so.
If you click on a taskbar tab, you activate
the application. Your fullscreen window stays on top
because of "wndTopMost" but the program you just clicked
on is the active application. This is normal behaviour,
the "always on top" feature.

I think you just can't see it because your application's
window fills the screen completely.

 
I do see the task bar when i press the windows key. The start menu appears as if I moved my mouse to the bottom left and clicked on start. Where my problem lies is lets say I have Outlook open as well. In the taskbar, i will see a rectangle button that says "microsoft outlook". When I click on that button, I expect to bring Outlook to the front (this is the behaviour on a single monitor system). What happens though is my mouse click is ignored and I just get my app back. I thought about capturing key presses as well but thinking it over, I realized a test to make sure the app remained on top would be consuming to the cpu.

Is there any other way to make the taskbar go below my app without using the wndTopMost in my app? This has been bugging the heck out of me since monday.

Matt
 
>When I click on that button, I expect to bring
>Outlook to the front (this is the behaviour on
>a single monitor system).

That's the point: If another (your) application
is 'always on top', Windows won't bring Outlook to
the front, but to the second position in z-order.

>What happens though is my mouse click is ignored
>and I just get my app back.

Does your app then has the focus any longer or is
it deactivated?

btw, MSDN says:
---
To set these options, the user must open the taskbar shortcut menu, click Properties, and select or clear the Auto Hide check box or the Always On Top check box. There is no way to set these options programmatically. [...]
---

But you can find out if one of these options is set.
Maybe this helps you to find a solution.
 
Ahhh... ok... looks like it might be time to play with the registry.

Thanks alot :D
Matt
 
Well... here is what I came up with so far. If I use

PreTranslateMessage i can capture the keypress of the windows key. So with that i can bring the taskbar back to the top. How do I test when my app gets focus again (and not test it over and over again so i dont hog the cpu)

Matt
 
I don't know if your application is using hooks. If not, take care not to capture the keyboard item with your 'always on top' windows.

Anyway, you can use hooks to VERIFY what is going on in fact.

Hope this helps,

s-)

Blessed is he who in the name of justice and good will, shepards the week through the valley of darknees...
 
Actually, I have never used hooks (at least to my knowledge) could you give me a base example of how they are used and I will expand off it?

Matt
 
I haven't used hooks myself for a time. Sorry to tell you that I do not have any code examples at hand(they are all at home).

But I can tell you this:
- Hooks are API specific, you can find no help with MFC
- Main commands are:

HHOOK hHook=::SetWindowsHookEx(arguments)
- to set the hook you wish, there are many type but I think you need the WH_MOUSE type for your hook

UnhookWindowsHook(hHook) - to stop the hook

CallNextHookEx(arguments) - to call the next hook in the hhok chain, because the can be more then one hook on a item.

Also you should read the "Hooks" and "Hooks overview" articles from MSDN.

Roughly said a hook is a callback procedure that is called by the OS when a specific event is called BEFORE passing the event further to the application in cause.(thats why you will need CallNextHookEx function)

Also, the CdTest sample from MSDN is using hooks.

If you make the time to catch a few things about hooks I think you will find them useful in different areas, too.

Hope this helps,
s-)

Blessed is he who in the name of justice and good will, shepards the week through the valley of darknees...
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top