I'm writing a Windows app that has a tray icon (displayed next to the system clock). The icon itself looks nice if I run it on Windows XP in a normal (console) session, but when I connect to the same Windows XP machine using Remote Desktop Connection the tray icon looks bad—with jagged edges on the side. Note that the rest of the tray icons look fine, it's just mine that looks crappy. So what is the secret here?
I faced the same issue in the past. You have to load icon with LoadImage function (not with LoadIcon).
Screenshots would be helpful, but I'm guessing it's to do with the colour depth that you're using in the two sessions. If the quality in one is higher than in the other, the icon may render differently.
You can change the colour depth in the display tab of the Remote Desktop Connection settings.
Related
Is there a way to temporarily disable the display during a Windows 10 PC restart?
Background: we have a software, which is set to start up automatically after a PC restart. Upon startup (after Windows has booted) this software starts in a console window and then opens a WPF screen, which is displayed fullscreen and always resides in front of everything else. I would like to black out the screen ideally as early as possible during the Windows startup up to the point in time when our software WPF window is set and ready on the screen. This way the console window (as well as the desktop showing for a short period of time) would be hidden from the user.
In an ideal world I would hide the fact that Windows is running on the PC from the user, but I assume this is not possible over a restart...
Is this possible with the help of registry settings/command line tools/batch file commands or similar?
I am creating a toolbar on Windows that is being ported over to the Mac, is there such a concept as a workarea on the Mac, like there is on Windows.
If you are unfamiliar of what the workarea on Windows is, it is basically a defined space that all open windows can re-size in. Meaning normally you can re-size your windows to fill the whole screen, but if I change the workarea to a smaller size when you try to maximize your open windows they will stop at the boundaries of the new workarea. For example the Windows taskbar does this. If you move your windows taskbar up or down, then this affects how much space you have left for open windows to utilize, the taskbar is changing your workarea dimensions.
Windows uses the following function SystemParametersInfo with SPI_SETWORKAREA passed into to change the size of a workarea. Is there an equivalent to this on the Mac?
Thanks.
Yes, there is a mechanism in OS X to keep maximized windows from overlapping the Dock. Look at NSScreen's -visibleFrame method.
When I install a virtual desktop manager on Windows 7, and I switch to a different virtual desktop, all the current windows disappear, also disappearing from the Start Menu.
I want to hide some of a particular application's windows, but not all of them, in a similar manner. How can I hide a window like this?
In particular, I need to hide a VirtualBox Seamless mode window, so I'm not sure minimizing the window will work. It does, however, disappear when using virtual desktop managers.
The same window cannot appear on multiple desktops. If you need your application window to appear on multiple desktops you need to create a separate window for each desktop. The desktop a window appears on depends on the thread that creates the window. You can change the desktop thread assignment using the SetThreadDesktop function.
The answer is simply ShowWindow(SW_HIDE) and ShowWindow(SW_SHOW). I think "Virtual Desktop Managers" just hide windows and show them as necessary when the desktops change.
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.
I've got an windows mobile 6.5 application I'm developing and am having trouble with one icon. At the top right hand of the screen there is an icon that, when clicked, will display a list of programs running the background with the option to close them.
When my program is in this list, it's icon does not show up as the others do.
I'm my exe I've got an .ico for 16x16, 22x22, 32x32, 36x36, 44x44, 45x45, 60x60, and 64x64, with the optional 90x90 png and registry setting in my cab.
What am I missing?
I'm just guessing here, but is this an HTC phone? Stock Windows Mobile does not have a "task list" icon in the system tray, so this task list is provided by the OEM. You would need to find out how they are obtaining the icon.
Chances are they are not obtaining it from the cab, but are actually getting it from your top level app window. You should check you're specifying the right icon in your WNDCLASS structure when calling RegisterClass. It is pretty common in WM to forget this because normally this icon is not visible.
Windows Embedded Handheld (Windows Mobile) 6.5/6.5.3 Appications use the exe embedded ico files only if there is no icon via registry available. In those cases the icon also look very ugly in the start menu. So you will have to add a registry entry to an icon file.
[HKEY_LOCAL_MACHINE\Security\Shell\StartInfo\Start\MyApp.lnk]
"Icon"="\Windows\myapp.png"
See also: https://blogs.windows.com/windowsexperience/2009/08/11/using-custom-icons-in-windows-mobile-6-5/