How do I get the dialog box titlebars to be thick in my applications like the dialog boxes in Windows 10. I have noticed a behavior where if the minimum Windows version is set to 6.0 or higher in the linker options it will cause the titlebars to be thick.
I have <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/> in my application manifest yet if I set the minimum Windows version in the EXE file with the linker to 5.01 (for XP compatibility) the titlebars will be thinner.
The application is written in a mix of C and C++ and uses plain Windows API.
Is there any way to get titlebars in dialog boxes to use the non-backwards-compatible behavior without dropping XP support for my application?
In the end, I am pretty much convinced it is an internal behavior of the window manager, and as such I am now distributing two versions of my application: An XP-compatible version compiled in Visual Studio 2010 and a Vista+ compatible version compiled in Visual Studio 2017, which also requires a SSE2-capable processor to run.
What you can do is set your dialog box as borderless and draw your own title bar and close button. That would guarantee portability amongst all platforms, as drawing would then be entirely specified by your code, rather than allowed to the discretion of the operating system API.
Related
I've been encountering this issue ever since I bought this laptop with 4k display in 2015. With a lot of effort I managed to work around the issue but I'm growing tired of it.
VS2017 is supposedly DPI aware hence I do not expect any issues when creating a simple MDI Parent Form and running the app. But to my frustration the icons in the toolStrip (just the standard one in the MDI parent form) are scaled horribly.
When I create a form with a button on it which looks just fine in Visual Studio 2017 designer and I run the app and load the form, the button text isn't completely shown.
My display settings are as follows:
Resolution: 3840x2160
Scaled 250% (in display settings) because at 100% everything is unreadable
I've tried to find solutions, but the only workable thing I could find was setting my visual studio designer to dpi-unaware via registry (link here)
Help anyone?
Update When I add a new MDI form with the setting of DPI-awareness OFF, everything looks OK except Visual Studio itself (blurry).
I have similar problem when working with Windows Forms (Windows Forms Designer) on Visual Studio 2017, but I think it would be the same on Visual Studio 2019.
From Microsoft documentation here, there is a tip to disable the scaling/DPI aware feature.
If you prefer to manage settings from the command line, devenv.exe
takes /noscale as a command-line parameter to run in 100% scaling
mode.
So, basically, I just created a shortcut on the Desktop to Visual Studio (devenv.exe) and added the parameter /noscale on the shortcut Target field like so:
"...\path\to\IDE\devenv.exe" /noscale
So, everytime Visual Studio is started through the shortcut, it will always start with 100% scaling mode. If you use high resolution screen (high-dpi) screen, you will notice that the Visual Studio text will appear a little bit blurry because of this.
You should change the settings so there won't be a difference when the program runs on different machines.
Go to the project's properties page, then to Manifest Tool and then Input and Output. Change the DPI awareness to 'none'
I am debugging a Windows form application in visual studio 2012. How can i see the snapshot of the UI while debugging?
Print screen is built in to windows. Sometimes labelled "PrtSc" on the keyboard. Use Alt-printscreen to snapshot just the window. There is also a "Snipping tool" program available in some versions of windows.
In Windows Vista and Later, the Desktop theme may affect the appearance of the App UI when the code is frozen at a breakpoint within the debugger. In Windows 7, for example: with Aero theme enabled, the current app UI is usually still visible if other obscuring windows are moved or closed, because Aero retains an image of the UI. So, for example, minimizing Visual Studio will typically let you see the application again.
If Aero is disabled (eg switch to a Basic theme in Win 7), then the app UI will not respond to paint events, and if other windows on top of it are removed or moved, the result is gibberish. If working on 1 monitor, once Visual Studio stops at a breakpoint you will no longer be able to see the UI until the code runs and responds to any pending Paint events.
So, if your question was about the UI freezing when the code is paused, enabling Aero might solve it.
I know that XAML is used for designing UI in combination with Blend. I am confused with so many terms, like, how XAML comes into play for WPF, Store App, Phone App or UWA. Morever, what is the difference between WPF, Store App, Phone App and UWA. Does all that means that old Desktop Project will no longer be used and replace by either WPF or Store App or UWA?
When .NET was released in ~2000, you could use WinForms to make desktop applications for Windows. It provides access to 'native' controls (i.e. A Button made in WinForms actually is a Windows Button control from user32.dll) by wrapping the Windows API in managed code. These can run in any version of Windows which has the appropriate .NET framework version installed, including upto Windows 10.
In 2006, WPF was released which is an alternative to WinForms. WPF uses XAML, which is a language based on XML, to declare the user interface elements. In a simple WPF app, the .xaml file describes the GUI and the code-behind file describes the logic. DirectX is used to draw whatever is described in the .xaml into the window.
Like Winforms, programs made using WPF can run in any version of Windows which has the appropriate .NET framework version installed, including upto Windows 10. Note that using XAML is completely optional. Whatever user interface elements you describe using XAML can also be made using your .NET language C# or VisualBasic.NET. But using XAML is usually simpler. See To XAML or not to XAML (MSDN Blogs).
From XAML (Wikipedia) :
As XAML is simply based on XML, developers and designers are able to share and edit content freely amongst themselves without requiring compilation.
From ~2012 along with Windows 8, a new kind of app called metro/modern/windows-8/windows-store-apps can be made. These apps are similar to WPF in that they use XAML for describing the GUI. These apps can run only in Windows 8, 8.1 and Windows 10. Windows 8.1 added some improvements and features but remained mostly the same. The same technology was used to make apps for Windows Phone.
With the release of Windows 10, Microsoft made UWP (Universal Windows Platform) through which you can use the same code base to target differnt kinds of devices (desktop/mobile/xbox/IoT/holographic). These apps made for the UWP are similar to the earlier Windows 8/8.1 apps. Like before, XAML is used to describe the GUI.
Only for the Windows Store apps, there is no backward compatibility. The timeline goes Windows 8 -> Windows 8.1 -> Windows 10/UWP. An app made in UWP can only run in Windows 10 and an app made in Windows 8.1 can not run in Windows 8.
I would highly recommend referring to this discussion thread in stopbyte, it has far more details and explanation of the concepts behind WPF, UWP And WinRT.
As for WinForms, from my experience it's history now. Have been almost replaced by WPF (though it still has mainstream support as mention by #Jazimov).
I'v noticed that Microsoft has stopped improving Windows Forms and probably has stopped maintaining it as well.
We have an in-house .net 2.0 winforms app currently developed on Visual Studio 2005 in Windows XP. Everyone in the office until now is running Windows XP, and there are no issues.
We recently ordered a new computer with Windows 7 for one of our managers we were hoping to use, and the app installs fine. The issue is the spacing around every label, textbox, and button - making some forms not fit.
Is there some setting that we can use to make Windows 7 display each control where it is placed in our XP development environment and like the rest of our XP clients show?
Ugh, what kind of idiot management team gives a new machine to a manager instead of a programmer?
Control Panel + Display, Advanced tab, change the DPI setting to repro the problem on your XP machine. Read the docs for the Form.AutoScaleMode to find out what's going on.
Under Windows XP WPF true 3D content (which is usually displayed using the Viewport3D control) looks extremely ugly because it is by default not antialiased as the rest of the WPF graphics are. Especially at lower resolution the experience is so bad that it can not be used in production code.
I have managed to force antialiasing on some Nvidia graphics cards using the settings of the driver. Unfortunately, this sometimes yields ugly artifacts and only works with specific cards and driver versions. The official word from Microsoft on this regard is that antialiased 3D is generally not supported under Windows XP and the artifact I see result from the fact that WPF already does its own antialiasing (on XP only for 2D).
So I was wondering if there is maybe some other secret trick that lets me force antialiasing on WPF 3D content under Windows XP.
Have you tried this (from your thread on MSDN forums)?
Well, it seems the reference in the MSDN link above incorrectly specify the affected registry root key. In MSDN it is specified as HKEY_CURRENT_USER, while the correct root key should be HKEY_LOCAL_MACHINE. I've tried setting up the HKEY_LOCAL_MACHINE\Software\Microsoft\Avalon.Graphics\MaxMultiplesampleType to '4' and I can get antialiasing for my WPF Application on XP.
The feeling I get from Matthew MacDonald's Pro WPF Windows Presentation Foundation in .NET 3.0 is that it's not possible:
There's one exception to WPF's software support. Due to poor driver support, WPF only performs antialiasing for 3-D drawings if you're running your application on Windows Vista (and you have a native Windows Vista driver for your video card).
I've never seen anything to suggest that you can enable AA in WPF 3D on anything but Vista, but if there is a way it's new to me and I'd love to know as well!
Does your video card support Shader 2.0? You can refer to this wiki page to see if it does...