Some months ago I had ported about 80% of the code to C# (using both managed and p/invoke calls). Things came up and so I never got around to finishing it. I will see what I can do and post and article on it sometime in the future.
First, excuse my bad english (it's not my native language, I'm French).
Then, I'm a studient and I have to create a programm which could hide/unhide any icons in the systray (even extern processes' icons) in VB or in C/C++. Do you know a way to do it?
I can suggest one more approach (not perfect, but worth considering, I think).
Having found the tray window you can send WM_MOUSEMOVE to it with different coordinates trying to guess the icon location. As soon the message is forwarded to your application (wrapped in the message specified when calling Shell_NotifyIcon) you have found it.
if the taskbar is hided the arrow of the balloontip appears outside screen, and it should call the taskbar up, like any normal infotips displayed in the taskbar (eg. see how the XP SP2 security warning does). This ballon instead points to the outside of the screen and it's not painted entirely.
Does anyone know if there is an official mechanism (or have unofficial ideas;)) to keep a tray icon active so that Windows XP does not "hide" the inactive icon? I assume that by updating the icon periodically, I can keep it "active", but that seems inefficient.
Hmmm... my display settings are actually "big fonts" (120 dpi) and it seems to work perfect.
Scaling the icon is not a problem for this code since plain black icon scaled to be larger will also be a black icon.
That was the only reason i could come up with for it not working on my Win XP system. the only other variable is that I have the task bar at the top of the screen. Anyway I've worked out a way to do the same, without any image processing, See below.
The codes is in vb6 but you should be able to easily convert it. The call to GethWndTray (which gets the tray's toolbar control has been ommited for compactness.
Private Type TrayData
hWnd As Long
ID As Long
Public Function GetSystemTrayItemRect(ByVal hWnd As Long, ByVal ID As Long) As RECT
Dim hWndTray As Long
Dim hProc As Long
Dim pid As Long
Dim vaPtr As Long
Dim ret As Long
Dim tbut As TBBUTTON
Dim cButtons As Long
Dim td As TrayData
Dim i As Long
Dim rc As RECT
hWndTray = GethWndTray
If hWndTray = 0 Then Exit Function
Call GetWindowThreadProcessId(hWndTray, pid)
If pid = 0 Then Exit Function
hProc = OpenProcess(PROCESS_VM, 0, pid)
If hProc = 0 Then Exit Function
vaPtr = VirtualAllocEx(hProc, ByVal 0&, Len(tbut), MEM_COMMIT, PAGE_READWRITE)
If vaPtr = 0 Then GoTo cleanup
For i = 0 To cButtons - 1
Call SendMessage(hWndTray, TB_GETBUTTON, i, ByVal vaPtr)
Call ReadProcessMemory(hProc, ByVal vaPtr, tbut, Len(tbut), ret)
If Not tbut.dwData = 0 Then
Call ReadProcessMemory(hProc, ByVal tbut.dwData, td, Len(td), ret)
If hWnd = td.hWnd Then
If ID = td.ID Then
Call SendMessage(hWndTray, TB_GETITEMRECT, i, ByVal vaPtr)
Call ReadProcessMemory(hProc, ByVal vaPtr, rc, Len(rc), ret)
Call MapWindowPoints(hWndTray, 0&, rc, 2)
GetSystemTrayItemRect = rc
If hProc Then
If vaPtr Then
Call VirtualFreeEx(hProc, ByVal vaPtr, 0&, MEM_RELEASE)
If hProc Then CloseHandle (hProc)
I have ported VB example you provided to C++ and it looks promising. The problem is that all you can retrive with this example it's rectangle of each button in a tray (cool!) and TBBUTTON structure. But TBBUTTON seems to be not enought to determinate witch one of the buttons belongs to our application. Especialy there is no HWND member and button ID member seems to have different values that this ID we specify while adding icon to the tray.
in VB code there is a piece of code: If hWnd = td.hWnd Then
If ID = td.ID Then
but in C++ definition of TBBUTTON of this structure there are no such members.
Anyone hve any idea how to solve it?
Copy the first 8 bytes of the dwData member of the TBBUTTON, using the ReadProcessMemory API as you did to get the TBBUTTON struct. The first 4 bytes is the hWnd the button belongs to. The second 4 bytes is the NOTIFYICONDATA.iUD.
Then using the index of the button you can then get the it's rect by calling TB_GETITEMRECT, again ReadProcessMemory is required. As seen in my earlier post.
There appear's to be alot more info in dwData but I just use the first 8.
Thanks for the feed-back.
I have just submited an update to souce code with:
BOOL CTrayIconPosition::CheckIfColorIsBlackOrNearBlack(COLORREF crColor)
>What do you think of using an icon with a white border (2pix for 32*32 icon) and calculate the exact rectangle of the icon?
I think that this could fail since there is no proof that border will not be disrupted by Windows. But I was thinking on a different approach. First you put a plain black icon into the tray and detect all black points, then put a bit lighter icon (dark gray) and check previously black pixels if now those are dark gray - is should stil take a blink of eye and be able to detect an rectangle of icon with a great precision.... I don't plan to implement this feature but (since simple point detection is enought in my applicatins) but I would gladly update souce code if someone would do this
This isn't good because the icon rect could move inside the tray rect
Instead we could track the mouse position from where the function gets called and see if fits the old icon rect. If not..scan for the new rect icon; at least this will lower the scan operations...especially on vista or later which requires visual scan only...that black icon.
//let's initialize tray icon position tracking
//second argument it's ID of icon (nid.uID)
// Add "About..." menu item to system menu.
sprintf(status,"Applicom = %d .Twincat = %d",Appli.GetStatusUnitel(),Appli.GetStatusTwin());
TrayShow(); // Show the tray icon
ShowWindow(SW_HIDE); // Hide the window
But when i call GetTrayIconPosition in CTrayIconPosition, it load a black icon. After what i refresh my icone in the OnTimer() like that: sprintf(status,"Applicom = %s Twincat = %s",mot,mot2);
Finaly, my problem is the menu is not attach to my icon and i have to restart my PC because Windows can't killed the thread.
This "Tray Icon" doesn't position itself correctly when the taskbar is on the left or on the right of the desktop. And the pointer in such situation looks real ugly.
Ultimate all-in-one XP-Style UI multiplatform solution: Tooltips, XP Menus, Hyperlinks, Drawing Graphics and formatted documents, plus powerful binary resource reuse. All Free 100% on www.tooltips.net. It can be used in VC++, C#, Java+, VB, Delphi, C++ Builder, as well as in any COM-compatible platform.
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