I want to turn the system network icon on/off in my application likes what we can do via control panel. I know the "HideSCANetwork" registry item, but to use this solution I need to restart the explorer after changing the setting. Is there any other solution which can do this seamlessly like the system?
There is no official API for doing thois. The reason for this is that Microsoft wanted to give the user the ability to keep their notification area from becoming too full. The problem being too many applications starting notification icons that the user doesn't care for.
Since many users don't know how to get rid of these icons, Microsoft decided to help by hiding them by default. If applications had access to these hide/show settings then applications would simply show the notifications by default and we'd be back where we started. So there is no mechanism provided for modifying these settings programmatically.
You want to do something different that sounds equally malicious, namely to hide an important system icon. If you are determined to do this then you can reverse engineer how the setting is stored (likely in the registry) and change the setting that way. However, you'll be going against the system design should you do so.
Now I find a imperfect solution. The basic idea comes from here:
http://www.codeproject.com/Articles/10807/Shell-Tray-Info-Arrange-your-system-tray-icons
Some tips:
This solution supports Win 7, you can remove XP checking code.
On wow64, you need to change the struct TRAYDATA and use TBUTTON64:
struct TRAYDATA
{
DWORD64 hwnd;
UINT uID;
UINT uCallbackMessage;
DWORD Reserved[2];
DWORD64 hIcon;
};
typedef struct _TBBUTTON64
{
int iBitmap;
int idCommand;
BYTE fsState;
BYTE fsStyle;
BYTE bReserved[6];
DWORD64 dwData;
DWORD64 iString;
} TBBUTTON64, NEAR* PTBBUTTON64, *LPTBBUTTON64;
typedef const TBBUTTON64 *LPCTBBUTTON64;
When you find the icon you want to hide(By using the tip text plus the owner process), send a TB_HIDEBUTTON message to the notification area window.
The imperfect part is that the tray icon will be hidden, but the notification area will not resize. So there is a blank area on the notification area.
Related
I wonder if there is any way to somehow interact with windows that are currently open on a Windows system. I am interested in getting some of their properties, namely:
Location
Dimension
is in background?
possibly window title
Preferably, I would like to do that in Java but any suggestions are welcome.
A comment by theB linked to good resources for Java. I'll run through the relevant Windows APIs, in case you want to go native with C++.
To enumerate all the top-level windows in the system, use EnumWindows. You give it a callback function with the signature of EnumWindowsProc, so it will receive each window handle as the first parameter.
You can get the window location (in screen coordinates) and dimensions with the GetWindowRect function. Pass in the window handle you received and get an LPRECT (pointer to RECT) out.
To determine whether a window is maximized, use GetWindowPlacement and check the showCmd field of the WINDOWPLACEMENT structure you receive.
Finally, to get a window's caption, use GetWindowText. (As an aside, if you want to get the text of a control in another process, you'll need to send the WM_GETTEXT message yourself.)
Explorer seems to always start my application with SW_MAXIMIZE (STARTF_USESHOWWINDOW is set in STARTUPINFO.dwFlags). I know that ShowWindow will use this value the first time you/Windows needs to display a window but it has the unfortunate consequence of maximizing a window that should never be maximized.
My window is created with CreateDialogIndirectParam and has the following styles: WS_CAPTION|WS_SYSMENU|WS_MINIMIZEBOX|WS_CLIPCHILDREN|DS_MODALFRAME|DS_CENTER|WS_VISIBLE. Why does ShowWindow not check if WS_MAXIMIZEBOX is set before allowing STARTF_USESHOWWINDOW to force SW_MAXIMIZE? Is this a bug in Windows?
This happens on a HP Stream 7 with Windows 8.1. I'm not sure if Explorer does this because it is touch enabled or because of the small screen.
Is this Explorer behavior documented anywhere and is there a way to turn it off? What is the best way to stop Explorer (or any other parent process) from affecting my initial window mode? (I don't want to block people starting me with SW_*MINIMIZE*)
WinVer.exe in system32 has the same problem:
My first thought was to turn off STARTF_USESHOWWINDOW in the PEB if the parent wanted me to start maximized but that is too nasty and undocumented so I have not tried that yet.
Preventing any kind of size change (which is OK for my application since it is just a "modal" dialog) sort of works:
case WM_WINDOWPOSCHANGING:
((WINDOWPOS*)lp)->flags |= SWP_NOSIZE;
return true;
The problem is that the window position is still set to 0 x 0 like a maximized window.
A better solution seems to be to detect and correct the problem after WM_INITDIALOG:
case WM_INITDIALOG:
PostMessage(hDlg, WM_APP, 0, 0);
break;
case WM_APP:
if (IsZoomed(hDlg)) ShowWindow(hDlg, SW_SHOWNOACTIVATE);
break;
I am the proud owner of several HP Stream 7 tablets and I would like to add my 2 cents here. Microsoft has made an arbitrary decision that devices with screen sizes smaller than 8 inches will behave differently than the norm. A lot of users are somewhat aware of this, but unaware that this is where your problem originates.
Windows determines a screen's size by reading the EDID information from the screen, which contains sizing information in it, in centimeters.
If no sizing information is present in the EDID, or the sizing information is below Microsoft's arbitrarily chosen 8 inch threshold, you get this apparent misbehavior which is at the very least, aggrivating to those who notice it and don't want it.
The solution is to override the default driver for the monitor in Device Manager with one that informs Windows that the screen is in fact, 8 inches or larger.
To do so, you need to first read the EDID information from the registry with a tool such as Deltacast's E-EDID Editor (free, last time I checked), and modify the size values and save the modified file someplace you can find it.
After you have modified your EDID file and saved it, download Monitor Asset Manager from EnTech (also free) and use it to create an INF file.
Once the INF file has been created, you need to restart Windows with the Advanced settings menu and choose to Disable Driver Signing Enforcement, since the INF file you created won't be digitally signed. Once disabled, open Device Manager in Windows and update the driver for the monitor using the INF file you created. You will need to confirm that you do in fact want to install the unsigned driver file.
Reboot and Windows will now behave normally with the one catch that, the onscreen keyboard will now appear a different size and will have more options available.
Sadly, Microsoft can change this behavior in the future, so there is no guarantee that through the same flawed decision making process they used to implement this in the first place, they won't force it down our throats again, using a much more difficult to counteract method.
My purpose is to size a window to a width/height greater than the size of my physical screen programmatically under Win32. How can I do this?
On my systems it seems the maximum size of a given window is bound by the size of my screen whether programmatically or whether sizing manually by dragging the sizing cursor.
I have tried programmatically with SetWindowPos() and MoveWindow() and both cap the size of the target window. Oddly I know some people do not have this 'cap' so I wonder whether this is perhaps due to some OS setting (registry). Does anyone know something about this? Or perhaps some way to workaround it?
// Edit: new developments
I am testing on Windows XP and Windows 7. The graphics cards I'm using are a NVIDIA Quadro NVS 290 (256MB) and a Geforce 9800GT (1GB). After further investigation it looks like Windows is intercepting the message and fiddling with the parameters. For example, if you call SetWindowPos to make a target 2000x2000 it will only receive a WM_SIZE for the capped x/y.
Implement a message handler for WM_GETMINMAXINFO to stop Windows from applying the sane default behavior:
case WM_GETMINMAXINFO: {
DefWindowProc(hWnd, message, wParam, lParam);
MINMAXINFO* pmmi = (MINMAXINFO*)lParam;
pmmi->ptMaxTrackSize.x = 2000;
pmmi->ptMaxTrackSize.y = 2000;
return 0;
}
Windows with a thick frame (to allow user resize) are restricted from growing larger than the desktop.
Try SetWindowLong() clearing the THICKFRAME (0x40000) flag.
The following should allow programatic sizing, but the user will lose the ability to resize. If you add the Thickframe back after sizing, the user can resize, but when he does so the window will immediately shrink back to the desktop limited size.
The following is from some csharp code that also removes all borders, caption, etc:
WS style = (WS)GetWindowLong(ptr, GWL_STYLE);
style = style & ~WS.BORDER & ~WS.ThickFrame & ~WS.SYSMENU & ~WS.CAPTION | WS.POPUP;
SetWindowLong(ptr, GWL_STYLE, (int)style);
A good tool to play with window settings is uuSpy.
It's like Microsoft Spy++, but allows you to modify settings like THICKFRAME.
Yes, windows can be larger than the screen (or even the sum of all your monitors). Windows can also be positioned off-screen (which some applications do as a hack to hide while remaining active).
Perhaps the Windows 7 desktop manager is kicking in and trying to "dock" those windows to the edges of your screen for you.
You might try using the slightly lower-level API SetWindowPos, which gives you control over notifications, z-order, and other stuff.
You can get a window to be larger in resolution (and even way way larger) than your screen, using the 'Infinte Screen" software:
http://ynea.futureware.at/cgi-bin/infinite_screen.pl
Here's how to use it:
Download it, run it.
In the Oversize tab, choose the Windows you want to enlarge.
Give it the Width and Height you want. Done!
Just in case you need a large screenshot (that's how I ended up here):
If you want to get a screenshot of the window, you've got a screenshot option in the same Oversize tab. (Because screenshots are normally no bigger than the screen size, even if the window is larger). Another (and better) way to screenshot the window is using Greenshot, as you can save them in .tiff and directly watching the window.
I am calling querying the extended window styles of a window using the GetWindowLog property and it is returning values in many cases that are not documented in msdn.
Particularly 0x00000800L and 0x00000100L or a combination of the two. Does anyone have information about these values, or a more complete list than what is documented on the msdn site?
I ran across this thread while looking for an answer to why this value changes when Microsoft Word "disappears" a window. I maintain an app that tracks the HWND values in order to do application sharing. This works well, but Microsoft Office applications often handle these in unusual ways. In this particular case, I found that if you do the following in Microsoft Word 2013:
Open two new documents in separate windows.
Save the HWND values for both windows.
Close one of the two windows.
Both HWND values will, when interrogated with the IsWindow, IsVisible, etc Windows functions, appear to be normal, still visible, etc. There's no way I can find to tell that one of the windows has been closed -- except this undocumented dwExStyle value. 0x800 will be 'on' in the window that's still visible, and 'off' in the window that isn't visible any more.
(BTW, I know you're not "supposed" to save HWND values this way -- but try tracking windows for sharing without saving this value -- not so easy!)
Since 0x00000100L is listed right on the Extended Window Styles page it is a little unclear to me if you mean the normal or extended style so I'll describe both.
Style:
Dialog & old (user32) controls
0xFFFF for control/dialog specific styles
Common control:
0x00FF is generally used by the shared common control styles (CCS_NORESIZE, CCS_TOP etc)
0xFF00 for control specific styles, for a toolbar you would have TBSTYLE_LIST, TBSTYLE_TRANSPARENT etc
ExStyle:
0x00000100L=WS_EX_WINDOWEDGE
0x00000800L=Don't know, undocumented flag maybe (Edit: ReactOS has/had 0x00000800 as WS_EX_MAKEVISIBLEWHENUNGHOSTED, that does not mean that it has the same meaning on windows since ReactOS is not 100% compatible with windows)
Jeremy, this is just a bug of GetWindowInfo (for any OS after Win98: 2k, XP, Vista, Win7).
see http://rsdn.ru/forum/winapi/3362548.all.aspx ("WINDOWINFO.dwExStyle error")
try small tester therefrom: http://files.rsdn.ru/42164/wi_exstyle.zip
kero
Is there a way to determine if a menu is dropped down in the win32 api? Something that could be used like so:
HMENU hMenu = GetMenu(hWnd);
HMENU hSubMenu = GetSubMenu(hMenu);
// Is hSubMenu dropped down?
I'm not sure of a way to operate specifically on HMENUs to see if the menu is showing (and a quick scan of the platform SDK docs didn't turn up anything specific), but you might be able to use the GetMenuItemInfo function to get a MENUITEMINFO struct relating to the menu item which owns the dropdown. If the fState member has MFS_HILITE set, that should indicate that the item is selected and the sub menu is most likely open. Correctness isn't guaranteed on my part but it's worth experimenting with.
Another possible option would be using FindWindow with the class "#32768" to find the hWnd of whatever menus may be open, and sending the MN_GETHMENU message to whichever windows you find to retrieve the HMENU and compare it to the expected value from GetSubMenu.