That's not true. Position is beign calculated correctly.
This is rater bug in CBalloonHelp class that is not able to display balloon with such anchor points in a nice way.
Please relly on coordinates that application returns rather than the outlook of third-party-created balloon.
First of all this article describes CTrayIconPosition class and have nothing to do with CBalloonHelp class by Shog.
The most important data that is being calculated by demo application are X/Y coordinates of tray icon. While creating demo application I had to decide how to display those coordinates - at first I was thinking about simple MessageBox with such kind of message: "Icon found! Coordinates X[xxx] Y[yyy]."
But since I use balloon class in my applications I thought that it would be a good idea to not only show the raw coordinates but also display example of usage of this class.
So while testing this class - please compare COORDINATES given in result with position of your tray icon. Balloon is only example of use of this coordinates.
As you suggest balloon looks ugly when task bar is in left or right part of the screen - that's true. But it has nothing to do with CTrayIconPosition class described here.
I think that far better place to point this bug is CBalloonHelp discussion forum (link on the beginning of article).
CTrayIconPosition was not checked under multi-monitor environment. But I don't predict any problems - if I'm wrong - let me know about that.
I hope this will clarify some things and there will be no more misunderstandings.
What about sending WM_MOUSEMOVE directly to that window with client coordinates that jump by 16 pixels across the area? Then you have no bitmap scanning or anything like that, and you just catch your WM_MOUSEMOVE being sent in your code. Probably a little faster.
I spent some time investigting this possibility.
Since it seems to work - it has one serious disadventage.
I have few applications in my tray and one of them started to dispaly a tool tip while recieving WM_MOUSEMOVE mesage. I'm afraid that is not acceptable.
I'm going to spend more time on this matter but seems to me sending fake messages could lead some tray applications to behave strangely.
Actualy I was trying few ways to send this WM_MOUSEMOVE message. I'm afraid if I was able to find one application that actualy cares about WM_MOUSEMOVE - there could be more such applications installed on PCs of my users. The problem is that there is no way to guess if fake messages you send will be ignored by tray applications or not.
But thanks for poiting this idea - it could prove usefull someday!
I haven't done a whole lot of programming, but wouldn't it be possible to look up the messages windows sends and create a new one? If no other programs recognize the new message, then there shouldn't be a problem.
Although this relies on MicroSoft having coded their default window handler well...
Basically the problem is the tray window only forwards messages to the tray client which it thinks it needs(mouse messages only). So if you were to post a registered message or somesuch to it, first of all it has no corresponding item to send the message to(no coords/etc, not an input msg), and secondly it'd just throw it away since it only forwards the mouse msgs.
You're right. This is (with little difference) the way my SndVol33 works. You can check this program at http://users.info.kuzbass.net/~nav/. I wrote it long time ago, and it don't work under XP. IMHO - it's better to use DeskBand for such tasks.
Well - this will be a bit off topic - but in my oppinion you should reconsider that.
If user keeps his taskbar hidden ussually he wants it to be hidden - and this user can find your application irritating if it would be restoring something that is soppoused to be hidden.
Just my point of view
Then detection will fail - BUT this class is able to detect that is run under XP and if so - it will return you a point of hide/unhide button. In my case balloon messages comming from this button were looking perfect (like your tray icon was trying to shout from a grave ;-D)