I have a mixed mode win form app that does numerical analysis and then creates a report using COM automation on MS Word.
The app has a status window that shows the progress of the analysis. After the COM automation finishes creating the word DOCX report the app's appearance changes when running on Windows 8.1. There is no change on Windows 7.
The situation occurs if the winform app is x86 or x64.
The version of MS Word is 2007 x86 version.
Here's the original look of the form:
http://codeinsight.com/Pub/G31_Win8_Before.jpg
After running the app and the report is created it looks like this:
http://codeinsight.com/Pub/G31_Win8_After.jpg
The window shrinks and some fonts shrink too.
Can anyone give me a clue as to what is happening? And why it happens on Win81 and not on Win7?
Right-click on Word shortcut on the desktop (or on programmes), Select "Properties" and display "Compatibility" tab.
There is a checkBox "execute with a 640x480 resolution".
If it is checked, uncheck it.
If other options are checked, uncheck all.
Using the hint from Graffito's answer I was able to resolve the issue. I checked the "Disable display scaling on high DPI settings".
Related
I am coding a C++ project using MFC in Visual Studio (v16.5.4). The dialog editor seems badly broken on my HiDPI monitor (Lenovo ThinkVision 2880x1800 at 175%). It works fine on two other computers with standard monitors.
The dialogs get resized apparently randomly, and controls do not move correctly when I try to edit them. When I try to align controls the dotted selection rectangle may move, but the control often does not (in the editor). Sometimes, re-opening the editor shows that the control has in fact moved. When I build the project, the final display layout cannot be predicted from what appears in the resource editor.
I reported this to Microsoft using Visual Studio feedback, but they closed the report, saying it was "By design"!!!! They posted a link describing a feature which disables HiDPI awareness, but the link was for the Windows Forms Designer, not the MFC resource editor - there is no equivalent feature in the latter that I could find.
Does anyone else have this problem, or know of a decent work-around? At the moment I am transferring to my other computer with the standard display whenever I need to edit a dialog, which is monumentally inefficient for quite a large project.
I know this is an older post, but I thought what I found might help someone. I experienced the same issue today. It just happens that I have one monitor setup for 125% and one setup for 100%. The MFC dialog editor alignment operations do not work correctly on the 125% monitor but work fine on the 100% monitor. It would appear Microsoft isn't properly handling DPI in the dialog editor.
I am coming across a strange issue with my Firemonkey application. Here is a screenshot of my application when run on my local Windows 8.1 machine. Inside the blue panel, is an auto sizing label with a purposely long description to make sure the sizing is working.
Everything seems fine, until I run the same application on a particular remote machine. Here is a screenshot of the same application, running on a remote Windows Server 2008 R2 machine.
As you can see, the label inside of the blue panel is now being truncated, despite its auto size property being set to true. Additionally, the "Show Logs" button has it's text truncated as well.
In addition to verifying the auto size property of the label, I have tried running the remote machine at different window sizes to see if the issue had something to do with screen resolution. However, the label continued to be truncated.
Does Firemonkey have any known issues with drawing things differently across different operating systems? Are there any display settings on the remote machine that could cause the application to render incorrectly? Anything else I should looks at to try and narrow down / resolve the issue?
By default, TLabel is set to WordWrap = True. Try setting it to false. I had a similar problem on mobile devices and turning WordWrap off fixed it.
After tinkering around with a bunch of settings both in XE8 and on Windows I finally found the solution. The machine running Windows Server 2008 R2 had all of its visual enhancement settings turned off which caused the application to render in correctly.
The specific setting which needed to be enabled was "Use Visual Styles on Windows and Buttons". It appears this setting has to do with Aero as it is not available on my Windows 8.1 machine.
To get to this setting, navigate to:
Control Panel -> System -> Advanced System Settings -> Advanced Tab -> Settings Button in Performance Panel -> Visual Effects Tab -> Check "Use Visual Styles on Windows and Buttons"
With this setting enabled, I was able to get my application to render correctly. Additionally, I was able to replicate the problem on other machines by manipulating this setting.
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.
I noticed that the sample apps from QT show their menu bar as opaque, and with a color that doesn't match any of the styling on the window. It seems as if the windows being created by QT when running on Vista or Windows 7 don't pick up the translucency that are no the mainstay of the new Windows look and feel. Is there a way to override this in QT, or even have a custom painted menu?
On Windows 7 there is a special flag that activates the "Glass" Look&Feel:
Here is some more detailed information:
http://labs.trolltech.com/blogs/2009/09/15/using-blur-behind-on-windows/
Screenshot http://labs.trolltech.com/blogs/wp-content/uploads/2009/09/blurbehind2.png
From what I see, only the Qt::WA_TranslucentBackground flag is involved.
All of my Qt applications look native on Vista/Win7, including the "glass" frame. This is all by default.
I must admit I don't know where you got this idea that they don't. Here's what the Browser demo that comes with Qt looks like on my Win7 machine.
alt text http://img28.imageshack.us/img28/5535/qtacrossplatformapplica.png
I can't see anything wrong with it.
I've forced with a possible bug feature of MFC Feature Pack under Windows Vista. It can be easily recreated:
Create a new SDI app using MFC Feature Pack (with Ribbon based interface). You can also add some floating panels if you want;
Do not change anything, just build a Release;
Close the Visual Studio, run the application and turn your computer into Sleep Mode (Hibernation).
Restore the computer from the sleep mode and you will see that the application did not restore well: it does not correctly display window's caption; it is impossible to increase the window size (it cuts the frame), etc.
Did anyone forced with this behavior?
I'm using Windows Vista Business SP2 and getting the same behavior on my desktop and laptop. Unfortunately did not tested under XP or another platform.
PS: I've solved the mentioned problem for toolbar based application by switching the visual style to any other and back on receiving WM_POWERBROADCAST. But the trick does not work for ribbon based application.
I had the same problem, thanks for the tip, and looking for it I found a solution, I only tried it in an app with toolbar, I have not tried it in Ribbon, if it works in ribbon confirm me please.
What works for me:
// add to class CMainFrame :
UINT CMainFrame::OnPowerBroadcast(UINT nPowerEvent, UINT nEventData)
{
// Comment "default return" and return true
//return CMDIFrameWndEx::OnPowerBroadcast(nPowerEvent, nEventData);
return true;
}
Source: msdn forum.