0

I have a class that accesses the win32 API to pull the location, size, state, and edge of the taskbar. I use the class to know where to create alerts depending on where the taskbar is. I have a method that updates the alerts location depending on when the taskbar is when a new alert is generated or deleted.

Is there a way to detect when the taskbar moves so I can call the update method? That way if a user moves the taskbar the alerts move to the appropriate location instead of being in a ridiculous location until a new alert comes or one is deleted.

My thought was to have a timer checking against the current taskbar object i generated last with a new one every second or so and calling the update method if something changes. I'm just wondering if there is an "easier" or "better" way to do this.

(Using Visual Studio 2010 C#)

TL;DR Need to detect when the taskbar moves to call a method.

flip66
  • 341
  • 2
  • 5
  • 17
  • 1
    No. Just don't, users don't constantly move the taskbar around. Pinvoke SHAppBarMessage() with ABM_GETTASKBARPOS to find out where the bar is located to position a new alert window. If you want to do that in a timer tick then there's nothing really wrong with that, as long as you don't do it every millisecond. – Hans Passant May 19 '12 at 03:10
  • 3
    The proper way to accomplish this would be to ask for the task bar position immediately prior to displaying your alert. Being notified when the taskbar is moved or using a timer would then be totally unnecessary. – Ken White May 19 '12 at 03:26
  • I already have it looking at the taskbar location when the application starts or when a new alert is generated/deleted and then updating the location of the alerts. My problem is this alert system will be used rarely, but the alerts will probably be left on screen for a period of time on a users computer until the issue ends. So the chance of the taskbar moving, but the alerts not moving could be an issue that people will complain about. – flip66 May 19 '12 at 03:53
  • Polling is not desired in my case. We have an app that covers most of the screen, with the exception of a few pixels on each border of the screen. This small border allows for the taskbar to become shown if the mouse is moved to the edge where it is hidden. SHAppBarMessage will do what I need, but I would like to set it to fire upon the event of the Taskbar moving, whether being unhidden, moved to another edge in properties, or resized. Simply saying that your average user won't do these things on a regular basis is unacceptable. – Jason P Sallinger Oct 26 '15 at 16:07

1 Answers1

-2

General idea, you should subclass the taskbar window. As you may now, every window defines what is called a WndProc (window procedure) that handle all the messages sent by the system or other windows.

You can't have direct access to this function but you, can using the right API (SetWindowLong), redirect the message flow to another WndProc function of your choice (remember to call back the old WndProc so that the target window function normally).

By doing that you can monitor all the messages received by the targeted window. In particular, the WM_MOVE message in your case.

This is a simplistic explanation, I recommend reading about it thoroughly.

here's a starting link:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms633569(v=vs.85).aspx

Samy Arous
  • 6,794
  • 13
  • 20
  • 3
    -1. This is just wrong. Subclassing the taskbar window is a last-resort hack that should be avoided. You add the overhead of your function being called for every application in the system that starts after yours, and introduce problems if yours crashes or has an error for some reason. If you feel the need to subclass a system-level windproc for some reason, you're probably doing something wrong. – Ken White May 19 '12 at 03:23
  • There is no such thing as an overhead on your function being called.... This is not a hook. I think you are getting the wrong idea. – Samy Arous May 19 '12 at 03:26
  • OK. -1 for subclassing unnecessarily when there are better solutions. Replacing the WndProc when not needed is wrong. Better? You don't need to "monitor all the messages received by the targeted window" when all you're interested in is where you can show an occasional alert. You don't need to catch the thousands of window messages that are sent in order to detect one that happens very rarely. – Ken White May 19 '12 at 03:28
  • You are overestimating the impact of subclassing. You would be surprised to know how much this process is used. anyway, this is not the place for such discussion :) Is there better solution, may be. Is it a bad solution, I don't think so. But again this is my opinion. – Samy Arous May 19 '12 at 03:41
  • 3
    You are underestimating it. This is merely a good way to crash Explorer. You cannot subclass a window owned by another process without also injecting the code into the process. – Hans Passant May 19 '12 at 03:44
  • Sorry, you're missing the point. Think about it in other terms: "I'll intercept every phone call made to my area code and prefix; if it's for me, I'll answer it, and if it's not I'll send it on to it's original destination." Logical? I don't think so. :) But as you said, it's your opinion, and I've expressed mine with my vote. :-) – Ken White May 19 '12 at 03:53
  • it's more like intercepting my neighbor phone call (and only my neighbor's) and check if some of the calls are interesting. Anyway, I'm not rumbling about the vote. I've started developing for windows at times where sub classing was done systematically (And I'm sure it is still done), even if most of the time it was intraprocess. I understand your point. Not saying it is wrong. Just don't want people to throw away one of the basic techniques. – Samy Arous May 19 '12 at 04:02