I'm looking for a way to detect if the user is using small icons :
I couldn't find anything in GetSystemMetrics \ SystemParametersInfo.
I tried to use the "Running applications" window's size :
it works fine when the taskbar's orientation is bottom\top, but when it's left\right this window takes the entire taskbar width.
Any ideas?
Deskbands are not quite dead on Windows, but they are on life-support. First make sure if you don't want to take advantage of thumbnail toolbars, ITaskbarList3::ThumbBarXxx() functions.
I'm not aware of an api to read back the button size setting. There's a backdoor you can use, these configuration settings are always saved to the registry. Run SysInternals' ProcMon utility and change the setting. On my machine (Windows 8), out popped this registry key:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\TaskbarSmallIcons
That almost surely works, I can't guarantee anything beyond Windows 8 of course.
Related
I have a Windows shell extension that uses IShellIconOverlayIdentifier interface to display overlay icons on files and folders. My extension is a little like TortoiseCVS or TortoiseSVN.
Sometimes I need to make Windows Explorer redraw all it's icons. To do this, I call SHChangeNotify like this:
SHChangeNotify(SHCNE_ASSOCCHANGED, SHCNF_IDLIST, NULL, NULL)
This refreshes the desktop and right hand pane of any open explorer windows. It doesn't refresh the folder tree on the left hand side of any Explorer windows.
So I tried sending WM_SETTINGCHANGE like this:
SendMessage(HWND_BROADCAST, WM_SETTINGCHANGE, 0, 0)
on Vista this refreshes the folder tree, but not the right hand pane.
The combination of SHChangeNotify() followed by WM_SETTINGCHANGE seems to work quite well on Vista. But I still can't refresh the folder tree on XP if it is displayed.
Does anyone have any ideas how to do this better?
Is there a better solution for XP?
Sending SHCNE_ASSOCCHANGED is a bit like clubbing Explorer over the head. It causes the whole desktop to refresh quite violently and casues any open Explorer windows to loose there scroll position. Is there anything that's a bit less violent?
Does anyone have any ideas how to do
this better?
Personally I don't know. You mention the Tortoise programs which do a similar thing, so an excellent starting point would be to have a look at what they do in their source :)
These look to be the relevant source files that handle this problem:
TortoiseCVS - ShellUtils.cpp
TortoiseSVN - ShellUpdater.cpp (username: "guest", password: "")
I note in the RebuildIcons method in each of those will:
set the shell icon size or colour depth to a temporary value
updates all the windows by broadcasting the setting change
resets the shell icon size or colour depth to the original value
updates all the windows a second time with a broadcast of the setting change
Perhaps this is part of the trick to get things working in XP.
Use spy++ to see what WM_COMMMAND message gets sent when you press F5 in windows explorer or find what menu message is used for view/refresh
Then use FindWindow to get the explorer window you want and send the WM_COMMAND recorded earlier etc message to it.
This is a fun way to control all sorts of Windows programs.
You can also send a WM_KEYDOWN message with the F5 keycode to all open explorer windows. This is a bit of a hack though.
I need that one of our computers, when it boots, automatically opens Internet Explorer. IE should be Full screen (without the border and the address bar.. totally full screen) and open a default URL (no problem on this, just set it as homepage). Then I would need that if a textbox inside this page gets focus then the on-screen keyboard should show up.
can this be achived with standard windows settings or do i have to write my own program with browser inside? if i write my own vb.net program, can the program be totally fullscreen (without the X to close and without seeing the task bar)
what we need to do is set up a sort of a internet station where random people can browse a given page without having a keyboard and without having the possibility to access the system.
thanks
I would say it is possible - but I have no idea how to achieve this. There will be a registry setting of some sort which SHOULD enable the keyboard. Sorry - I barely touched this areas :(
I have a hidden process that waits for non-standard hardware button messages and runs an application (with CreateProcess). No problem with the user disturbing, it's an action that the user approved himself. Everything is fine when it's usual layout with taskbar shown and multiply captioned and non captioned- windows. But the situation is different in XP and 7, when the current application is full-screen. Full-screen application in this case is window without borders having exactly the same dimension as the screen. Windows hides taskbar for such application even if it's always on.
In Xp, it's ok, the taskbar is being shown in this case and appication (for example calculator) also, the full-screen app is still visible in areas other than the launched app's and taskbar'. But in Windows 7 nothing visual happens, the full-screen app is still on and if I switch to taskbar, the executed application is there. I tried to solve it with SetForegroundWindow, BringWindowToTop, even AllowSetForegroundWindow(GetCurrentProcessId()) call for a window handle found with CreateProcess-WaitForIntputIdle-EnumThreadWindows, no change. So did something change since XP related to full-screen windows that officially documented?
Thanks,
Max
I would imagine that, if you have your own hardware device, that there is some API for generating "real" user input. Clearly the legacy keyboard and mouse, and now USB HID drivers (many of which are usermode I think?) have access to an API to do so.
Synergy+ for example can generate fake keyboard and mouse events on connected PCs, and the consequence of the faked input is windows switching activation normally.
So, my initial idea is for your usermode "Device" application to synthesize actual keyboard messages - SendInput seems a likely candidate for "the API that can "fake" real user input events.
Then, use an API like RegisterHotKey in your "UI" app to respond to the hotkey combination your device app generates.
Now, (assuming that SendInput IS generating user input events at the correct level), you should (from within the WM_HOTKEY handler in your UI app) have permission (because everything was "user initiated") to change the foreground window (to yourself).
Vista introduced the desktop composition feature. In short, all windows are drawing to a memory bitmaps and the Desktop Window Manager is then composing these bitmaps and drawing on a full-screen Direct3D surface. Full-screen windows do not participate in the desktop composition and get to draw directly on the screen (mostly because the majority of full-screen apps are games that need real-time screen updates).
In particular, this means that when a full screen app is up and running, it is covering the DWM composed image and the user needs to switch to a DWM-managed window for the DWM to start drawing on top of the full-screen app.
I don't have a good solution for your problem, unfortunately. One way to solve it would be to add the WS_CAPTION style to your app and then handle WM_NCPAINT/WM_NCCALCSIZE/WM_NCHITTEST yourself. This would allow you to lie to the DWM that you are a regular windowed application, but change visually your NC area to look like you have no title. However, this does require certain amount of additional code and might be a bit more effort you want to invest.
Another way you can try to solve your problem is to explicitly minimize your full-screen application window when launching the new process. However, you will then have to solve the problem of when to maximize it back again.
Btw, you might find the comments on this post from Raymond Chen interesting.
Windows supports multiple desktops and my guess would be that the full screen up is using a different desktop than the default one (where your application will be shown). A desktop object in Windows is "a logical display surface and contains user interface objects such as windows, menus, and hooks". For example, screen savers normally are started on a separate desktop.
You can find out which desktop an application is running on using Process Explorer:
Set Process Explorer to replace Task Manager and to run always on top.
When your full screen up is shown, launch Process Explorer by pressing Ctrl + Shift + Esc
Within Process Explorer, select the full screen process and press Ctrl + H to display the handles of this process
See the value of the Desktop item in the list. Usually this would be set to Default
If you know what desktop this app is running on you can start your process on the same desktop by first calling OpenDesktop to get a handle to this desktop and then pass it into the STARTUPINFO of your CreateProcess call.
We have a Linux based system that does not use a Window manager. When we start certain applications (for instance Firefox) from a terminal window (e.g. Firefox &) we find that no matter what we do, we can't get the application to display full screen.
If we run xrandr, it shows the default resolution is 1280x1024, but when we try to maximize Firefox (by pressing F11) the application is only sized to 1203x650.
Another application that seems to have the same problem is the evince PDF reader.
Our application is not configured to run a window manager (and we don't want to add one), so I'm wondering if there is something else that we can do to get these applications to render full screen.
Thanks...
Although you don't want to use a window manager, you might need to use a window manager.
I haven't dug into the X server sources around this, so I can't definitively say X requires a window manager to run properly. But as somebody who writes X client code, and hacks the X server, on minimalist embedded devices with small screens, low CPU power and no GPU... let's just say, all the major players in that space use one, and have good reasons for it.
If you want to avoid chewing up a lot of disk space, RAM or CPU power doing window management, you should check out matchbox. It's a low-footprint window manager designed to meet those criteria, and it's what many folks in that minimalist embedded space are using. My employer uses it on cell phones, configured so that only one app at a time is visible to the user, and the foreground app takes up the whole screen with no window borders. But you can use it other ways, too - Nokia uses it for their Maemo-based network tablets.
You could use xwit(1) to forcibly resize and place the windows. But as as far as I know, X11 in itself does not have the concept of a "maximized" window; the very idea is only added by most window managers and/or applications (like Firefox).
Does passing the "-geometry=1280x1024+0+0" option to Firefox help?
Oh, also... if you don't explicitly set a window manager, you might be unexpectedly falling back to the default X11 window manager. If you're not absolutely positive there's no window manager, you should check into this possibility.
I have a Windows shell extension that uses IShellIconOverlayIdentifier interface to display overlay icons on files and folders. My extension is a little like TortoiseCVS or TortoiseSVN.
Sometimes I need to make Windows Explorer redraw all it's icons. To do this, I call SHChangeNotify like this:
SHChangeNotify(SHCNE_ASSOCCHANGED, SHCNF_IDLIST, NULL, NULL)
This refreshes the desktop and right hand pane of any open explorer windows. It doesn't refresh the folder tree on the left hand side of any Explorer windows.
So I tried sending WM_SETTINGCHANGE like this:
SendMessage(HWND_BROADCAST, WM_SETTINGCHANGE, 0, 0)
on Vista this refreshes the folder tree, but not the right hand pane.
The combination of SHChangeNotify() followed by WM_SETTINGCHANGE seems to work quite well on Vista. But I still can't refresh the folder tree on XP if it is displayed.
Does anyone have any ideas how to do this better?
Is there a better solution for XP?
Sending SHCNE_ASSOCCHANGED is a bit like clubbing Explorer over the head. It causes the whole desktop to refresh quite violently and casues any open Explorer windows to loose there scroll position. Is there anything that's a bit less violent?
Does anyone have any ideas how to do
this better?
Personally I don't know. You mention the Tortoise programs which do a similar thing, so an excellent starting point would be to have a look at what they do in their source :)
These look to be the relevant source files that handle this problem:
TortoiseCVS - ShellUtils.cpp
TortoiseSVN - ShellUpdater.cpp (username: "guest", password: "")
I note in the RebuildIcons method in each of those will:
set the shell icon size or colour depth to a temporary value
updates all the windows by broadcasting the setting change
resets the shell icon size or colour depth to the original value
updates all the windows a second time with a broadcast of the setting change
Perhaps this is part of the trick to get things working in XP.
Use spy++ to see what WM_COMMMAND message gets sent when you press F5 in windows explorer or find what menu message is used for view/refresh
Then use FindWindow to get the explorer window you want and send the WM_COMMAND recorded earlier etc message to it.
This is a fun way to control all sorts of Windows programs.
You can also send a WM_KEYDOWN message with the F5 keycode to all open explorer windows. This is a bit of a hack though.