Is it possible to set the DPI of an application programmatically or the DPI only possible to set through the system preference?
Note: My application's GUI is coded in MFC and .NET forms.
Update:
After some research I have found no way of doing this so I have to agree with the only answer here; it cannot be done.
Assuming that you are talking about the Windows system-wide setting that determines the ratio between the physical DPI setting (that depends on the physical screen + resolution), the simple answer is "you can't", at least, not on at the application level in a WinForms app.
What you can do, is add scaling code to your form, see this StackOverflow entry. Basically, set the AutoScaleMode to ScaleMode.Dpi. See the other entry for more info.
Related
Specifically I want to determine the state of the Windows setting for Mouse / Touchpad -> "Reverse scrolling direction" (which defaults to off). Ideally this would be extracted from the event data but a falling back to querying the current OS state would be sufficient. I wasn't able to find either solution in the MSDN documentation.
Note: That setting is only available in the mouse / trackpad settings on Windows 8 or Windows 10 and only if you have a precise scrolling device (like a Surface Pro 3).
I know of a few "standard" or "official" approaches to getting system information.
GetSystemMetrics
SystemParametersInfo
WMI
If none of these work and you can't find info in MSDN, then #Steve314's suggestion of checking the registry is probably the way to go. One approach to identifying the correct registry key:
Open the Mouse / Touchpad control panel and get ready to change the setting.
Download and run Process Monitor.
Change the setting in the Mouse / Touchpad control panel.
Search for RegSetValue calls in Process Monitor's output to try and find the one that corresponds to the setting you care about.
I wasn't able to find the scrolling direction via the other suggestions, but I was able to find the registry key using the Process Monitor suggestion. The registry key is:
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\PrecisionTouchPad\ScrollDirection
Thanks!
Just curious, from a standpoint of WinAPI developer, what desktop do Metro apps run in?
This stuff:
I didn't know that it would be such a secret... so I had to do some investigating and here's what I found:
First off, to answer my original question -- the Metro (or Modern UI) stuff runs in the exact same desktop as the "desktop" apps (pardon the pun.) It is actually all very simple. The short answer -- all Microsoft approved Metro stuff runs in the Internet Explorer_Server container (which, in layman's terms, is the Internet Explorer); or in the DirectUIHWND container (which is Microsoft's proprietary class that renders their undocumented UI), all in windows with the WS_EX_TOPMOST style turned on, which makes them render on top of the other content. And that is it!
Here's a couple of examples:
Let's split the desktop and use Spy++ to see what's happening under the hood:
So if we look into the "Weather" app window, it is nothing more than the regular (Win32) window of the class "Internet Explorer_Server" that is housed in the window of the "Web Platform Embedding" class, which in turn sits in the "Windows.UI.Core.CoreWindow" container that has the WS_EX_TOPMOST and WS_EX_NOREDIRECTIONBITMAP styles on:
If you look even deeper, all Microsoft's Metro stuff seems to run from the WWAHOST.exe process, which in simple terms is the container to run JavaScript for the Metro apps.
Now let's look into the Start Screen itself. Since it completely covers the desktop we need to use a different tool and its Shift key snapshot capability to get to it:
From it we can get the Start Screen's window handle (or 0x10158 in my case) and look it up in the Spy++:
As you can see from both tools, the Start Screen has window class DirectUIHWND, that is housed inside a window of the ImmersiveLauncher class, that is the one with the WS_EX_TOPMOST and WS_EX_NOREDIRECTIONBITMAP styles that make it remain on top. And that is the only difference between it and any other window created by a "desktop" app.
What is also interesting is how the "desktop" itself is rendered in case of a split-window situation. I originally assumed that in this case the desktop is simply shifted (or moved) to one side and resized, but that is not what happens... In reality (or in my Windows 8.1) in case of a split between a desktop and a Metro app, the metro app simply covers over the desktop, but the desktop itself does not change its position or size. In that case, only the taskbar and the existing desktop windows are moved and resized to fit the split. This could be illustrated by this diagram:
As a side note, such moving and resizing can be quite annoying for a user, since original positions and sizes of the desktop windows are not restored when the split goes away.
And lastly, a somewhat unexpected finding. I decided to check how Google folks were able to implement their Chrome browser (running as a Metro app) and found this:
Chrome renders in the Windows.UI.Core.CoreWindow class window, belonging to the Google's own process: "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe". So without going any deeper, it is evidently possible to encapsulate a Metro-style app in a non-Microsoft container, which is a good news for developers that don't care about AppStore XAML apps :)
EDIT: Forgot to mention, if you plan to show your own popup message from a Win32 process that is visible on top of a Metro app, you need to do the following:
Set UIAccess="true" in the process manifest. You can do so in the Visual Studio by going to Project Properties -> Linker -> Manifest Files and set UAC Bypass UI Protection to YES. (Note that you can keep UAC Execution Level as asInvoker, or not to require elevation of your process.)
Code-sign your process. It is important, since without a signature it won't work, and you'll see this error message: "A referral was returned from the server."
An alternative to signing (or for testing purposes on your development system) you can set the following registry key to 0. (I haven't tried it though, and I wouldn't recommend it due to obvious security concerns! But it seems to be another way to test it if a code-signing certificate is not available.)
HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\ValidateAdminCodeSignatures
Place the compiled executable file either into the %windir%\System32 folder, or more realistically into the %ProgramFiles%\Company\Product, or into the alternative %ProgramFiles(X86)%\Company\Product folder for your product's installation location.
Also you may consider reading Raymond Chen's article about this topic.
After that, when you set the WS_EX_TOPMOST style on your popup window, it will be displayed above any other windows, including the Metro apps, Start Screen, etc.
So in other words, doing this:
//You may also consider setting the WS_EX_NOACTIVATE style
::SetWindowPos(hWnd, HWND_TOPMOST, 0, 0 , 0, 0, SWP_NOMOVE | SWP_NOSIZE);
Can achieve this:
Since you say that your actual issue is knowing whether a Metro app is running, the answer is to call IAppVisibility::GetAppVisibilityOnMonitor. Pass the monitor you want to check. Note that this will give the correct answer regardless of what desktop the applications run in.
In linux and when installing packages etc. There are some installers that have a progress bar and a dos window which shows the files being extracted etc. How can i add this window to my C++ Win32 programs so that i can have it showing the tasks im doing? I cannot find any documentation on MSDN.
Question: How can i add a console window (if that's what its called, sure looks like one) in my program to show the details of the task at hand being done?
Here is a window with what i am asking.. (personal info so I erased the details. :]
You cannot embed a real console window inside another window (although a windowed process can have a separate console window). While it looks like a console window / command prompt, it is just a matter of appearances. What you want to do is create a sub-window/control with similar characteristics as a console window and then redirect the console output from the application(s) being run to append to that sub-window. For more information on how to do redirect the console output in Windows, see http://support.microsoft.com/kb/190351.
That "dos window" is a regular edit control: CreateWindow(ES_MULTILINE, EDIT, ...
However, it has the font set to a fixed-width one (Looks like courier). This is done by sending WM_SETFONT to the edit control.
#user995048 says "You cannot embed a real console window inside another window". But "cannot" is a strong word! I can run an entire virtualized computer in a window if I wish. :) So one can quite reasonably intuit that there are ways of doing what you say.
Sure, it is true that what you've seen are almost certainly cases of output redirection into a custom widget, designed to mimic the simple appearance of a terminal. However...if you want to embed one application's window inside another, there are things you can look into which might fit. Cooperative methods exist like GtkPlug, for instance:
http://developer.gnome.org/gtk/2.24/GtkPlug.html
To actually capture a not-designed-to-cooperate app's window and throw it in your app would be trickier. But possible, just as screen captures and virtual machines are possible. Probably best to avoid that sort of thing unless there's really a cause for it, though...
Try this
http://www.codeguru.com/cpp/misc/misc/article.php/c277/
link. I think the solution provided is what you need.
I tried it many years ago and it worked. I have not tried it in newer versions of windows though.
I always wondered how software such as iTunes, Winamp etc is able to create its own UI.
How is this accomplished under the Windows platform? Is there any code on the web explaining how one would create their own custom GUI?
WinAmp doesn't usually supply its own GUI at all -- it delegates that to a "skin". You can download dozens of examples and unless memory fails me particularly badly, documentation is pretty easily available as well.
From the looks of things, I'd guess iTunes uses some sort of translation layer to let what's basically written as a native Mac UI run on Windows (the same kind of thing that Apple recently decided was so evil that they're now forbidden on the iPhone and apparently the iPad).
Since saying anything that could possibly be construed as negative about Apple is often treated as heresy, I'll point to all the .xib files that are included with iTunes for Windows. An .XIB file (at least normally) is produced by Apple's Interface Builder to hold resources for OS/X programs, and compiled to a .NIB file prior to deployment. Windows doesn't normally use either .XIB or .NIB files at all, and it appears likely to me that Apple includes a compatibility layer to use them on Windows (though I've never spent any time looking to figure out what file it's stored in or anything like that).
Edit: (response to Mattias's latest comment). Rendering it is tedious but fairly straightforward. You basically take the input from the skin (for example) and create an owner draw control (e.g. a button) and render the button based on that input.
The easiest way to do this is to have fixed positions for your controls, and require the user to draw/include bitmaps for the background and controls. In this case, you just load the background bitmap and display it covering the entire client area of your application (and you'll probably use a borderless window, so that's all that shows). You'll specify all your controls as owner-drawn, and for each you'll load their bitmap and blit it to the screen for that control. Since there won't (usually) be a visible title bar, you'll often need to handle WM_NCHITTEST (or equivalent on other systems) to let the user drag the window around.
If you want to get a bit more complex, you can add things like allowing them to also specify a size and position for each control, as well as possibly specifying that some controls won't show up at all. Again, this isn't really terribly difficult to manage -- under Windows, for example, most controls are windows, and you can specify a size and position when you create a window. If the user loads a different skin at run-time, you can call MoveWindow to move/resize each control as needed.
I'm assuming that you mean creating a GUI application as opposed to a GUI framework.
There are lots of GUI frameworks available for Windows.
Some are
wxWidgets (www.wxwidgets.org)
Qt (http://qt.nokia.com/products)
And of course the venerable MFC framework (http://msdn.microsoft.com/en-us/library/d06h2x6e%28VS.90%29.aspx)
If you want a more complete list, look at the Wikipedia article for MFC (http://msdn.microsoft.com/en-us/library/d06h2x6e%28VS.90%29.aspx) and scroll to the bottom.
Each of these GUI frameworks is amply documented on the web.
I'm developing an application in C++ that's partially driven by touch-screen on Windows XP Embedded. Some text entry will be necessary for the user. So far we've been using the standard Windows On-Screen Keyboard (osk.exe), but there are two main problems:
It's rather small on a higher resolution screen which will probably make it hard for users to hit the right keys
It's too "ugly" for the customer, who'd like a slicker on-screen keyboard that integrates better with the custom look-and-feel of the application so far.
Therefore I'm looking for alternatives for the Windows On-Screen Keyboard (osk.exe) that allow a larger size of buttons and can be skinned. Ideally it would have a BSD-like license for unburdened integration into a commercial app, but a royalty-free commercial solution could work.
Do you know of any such applications, or have you had a similar project where you solved the issue in another way?
We are using Click-N-Type for our systems. It is completely resizable. It has some customization possibilities, but I never tried them. We use it on "normal" Windows XP, but it should work on Windows XP embedded also.
I know this question is tagged 'c++', but here's an option for .Net that I found and integrated with less than 5 minutes work. (I've looked, and there isn't a .Net flavour of this question, and I guess it could be ported to C++ with very little effort too).
It uses the standard Windows On-Screen Keyboard (osk.exe), resizes it, docks it to the bottom of the screen and removes the title and menu bars, all from one call in your application.
The Code Project - Manage Windows XP On Screen Keyboard
The download is a single VB.Net class.
please check WPF Component(http://fpscomponents.com/Product.aspx?id=8) that is fully customizable by inbuilt editor. So programmer can fill it with own language and define layout!
Check johngnazzo code:
http://www.daniweb.com/forums/thread4548.html#
Why not write your own keyboard UI? This would (should) be relatively trivial and give you complete control over its look and feel.
I programmed a On Screen Keyboard in Java.
This is working very fine when you want to tip into Java components and Java frames.
When you want to tip in every open window you have to send the key event by implementing Robot sender. The problem i have is that the focus owner get the sended key and when you open the keyboard the keyboard has the focus.
You can not realy implement a global Java keyboard, as far as i know.
When you only want to use the Keyboard for Java, use Java.
Otherwise you should use another language.
You should use a native language where you can handle the OS focus owner or a language where you can completly disable the keyboard focus but also can bring the keyboard to the front of the screen
Take a look at chessware virtual keyboard.
http://hot-virtual-keyboard.com/