I'm looking to control runtime themes in a way that is friendly for version control tools. Be it programmatically, or by some configuration such as a text based manifest file (but not the DPROJ file through the GUI project options).
Is there any such way?
For clarification: The DPROJ is not committed to git because it is auto edited by Delphi for no apparent reason, and contains the command line parameters that anyone can modify daily.
Thanks to #Remy's pointers, this is the code responsible for disabling themes using a custom manifest:
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="5.82.0.0"
processorArchitecture="*"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
The critical parameter is which version of Common Controls is used:
version="5.82.0.0" will disable themes
version="6.0.0.0" and above will enable them
Related
I create a new application with a form that needs to be displayed without scaling but as designed with a fixed dimension in pixels (Position is poScreenCenter for example). When setting Scaled to false, the form is instead displayed with some default width and height, ignoring the designed dimensions. Setting Scaled to true works, it is displayed as designed, but scaling is not wanted.
I have tried to set DPI awareness to None or Unaware, but this has no effect.
I got similar if not the same issues while porting huge CAD/CAM project from BDS2006 C++ -> RAD11 C++ as a test of functionality before purchasing new RAD11:
scaled up all VCL components
but not scaled all glyphs causing very small glyphs
not scaled some forms and dynamic panels causing scaled up components will not fit into their designed area
speed buttons containing Captions even if they should not
ManualDock is corrupting Width,Height causing scale is applied twice on docked windows messing up custom layouts
I was planning to change the sizes of problematic VCL components (really just few form sizes and all glyphs) with code at apps init (or maybe create some utility that adjust *.dfm files like I did before for app auto translations and other stuff before so I have parsers ready to go so that it would not be a big deal) and planning to obtain scaling needed for this either by winapi GetScaleFactorForDevice or by the bugged behavior of ManualDock in RAD11
However before that I needed to start my app with admin priviledges from within RAD11 IDE as I deal with device drivers and stuff that needs admin priviledges...
I found and follow this tutorial:
elevated-privileges-for-delphi-applications
Which Immediately solved all my scaling issues too so no need to handle those for me anymore... Hope it helps you too (maybe even the scaling off option will work again as should have not tested it yet).
Now the App is scaled but correctly (it behaves as not scaled app just bigger)...
So in a nutshell (if the link got broken in time) you need to Add to project a XML file with *.manifest extention like this one:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity type="win32" name="Here_Your_Project_filename_without_extention" version="1.0.0.0" processorArchitecture="x86"/>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
publicKeyToken="6595b64144ccf1df"
language="*"
processorArchitecture="*"/>
</dependentAssembly>
</dependency>
<!-- Windows Vista application security requirements. -->
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="requireAdministrator"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!--Windows 7-->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
<!--Windows Vista-->
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
</application>
</compatibility>
</assembly>
note that Here_Your_Project_filename_without_extention in 3th line just replace it with the projects name. After that you open your:
Project->Options->Application->Manifest
set Manifest file to custom and at the bottom browns and select the created manifest file ...
That is it just recompile your App and run ... Please let me know if it helped or not.
I tested this on Win10 and RAD11 C++ (trial version win32 target)
This let me thinking that scaling related bugs might be caused by something in auto-generated manifest (have no knowledge and experience with those so I am just wild guessing) file which is bypassed by this approach...
I think you also do not need to use the admin rights part of the manifest so you might want to change that once this is already working for you.
I'm working on a per-monitor DPI aware application with multi-monitor capability.
It's necessary to know the design-time PixelsPerInch of the Form to scale it according to the current monitor DPI if the Form is moved across monitors.
The problem is that I don't get PixelsPerInch consistently.
While debugging, in the form's overridden Loaded method I get the correct 120 value.
When running standalone, I get 96 (and so the form scales bigger).
I use Scaled property as false and rescale manually in DoShow with ChangeScale (also setting monitor index/boundsrect if necessary). Then on WM_DPICHANGED, if ever, rescale again (anyway it's not sent while debugging, probably because of the IDE).
All looks fine, just on standalone run it's larger.
Why do I get different numbers for PixelsPerInch? Or at which point should I request the design-time value of it?
I'm using XE7 at the moment.
With a standard (?) win 10 manifest, and call SetProcessDPIAwareness at the very beginning of unit initializations. I prefer it this way, so a "/no_dpi_aware" run is also possible with the blurry windows scaling.
Of course I can just hardcode "120", but I wouldn't like it.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity type="win32" name="xxxx" version="3.1.0.0" processorArchitecture="*"/>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" publicKeyToken="6595b64144ccf1df" language="*" processorArchitecture="*"/>
</dependentAssembly>
</dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker"/>
</requestedPrivileges>
</security>
</trustInfo>
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!--The ID below indicates application support for Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
<!--The ID below indicates application support for Windows 8.1 -->
<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
<!--The ID below indicates application support for Windows 8 -->
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
<!--The ID below indicates application support for Windows 7 -->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
<!--The ID below indicates application support for Windows Vista -->
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
</application>
</compatibility>
</assembly>
I have got a question with regards to upgrading asp.net mvc applications from v1 to v2...
I've noticed in the ASP.NET MVC v2 Release notes that we need to add this code (please see below) when upgrading, but it did not state what would be the purpose of it because I've tried experimenting some of my apps to asp.net mvc 2 without adding this particular section in web.config.
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Web.Mvc"
publicKeyToken="31bf3856ad364e35"/>
<bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
Would there be implications should I not place this?
Thanks!
What this code does is pretty much tells your entire project that if there happen to be any old leftover references to MVC 1.0, then it should instead go try and use the 2.0 version instead. And I believe this would be inherited by class libraries as well where you might forget to update references.
I'm trying to use WindsorControllerFactory (the latest 1.0.0.916 version) together with the new Windsor Castle 2.0 (again, the latest version). But I'm getting the
Could not load file or assembly
'Castle.Windsor, Version=1.0.3.0...
error when starting the Web application. Anyway, during writing of this question I managed to persuade the Web app to bind to new Castle's dlls by adding this block to the Web.config file:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Castle.Windsor" culture="neutral" publicKeyToken="407dd0808d44fbdc"/>
<bindingRedirect oldVersion="1.0.3.0" newVersion="2.0.0.0"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Castle.Core" culture="neutral" publicKeyToken="407dd0808d44fbdc"/>
<bindingRedirect oldVersion="1.0.3.0" newVersion="1.1.0.0"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Castle.MicroKernel" culture="neutral" publicKeyToken="407dd0808d44fbdc"/>
<bindingRedirect oldVersion="1.0.3.0" newVersion="2.0.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
So I guess I answered my own question, but I wanted to share this with anybody having the same problem. Or is there a better way (apart from compiling the MVCContrib sources myself)?
I'd like to build MvcContrib myself too, and put its source along with our project code.
We use the same approach. There is one issue with the last available MvcContrib (v.2.0.96.0). It uses Castel.Windsor v.2.1.0.0 that is not compatible with the latest version of Castel.Windsor (2.5.1.0): AddComponentLifeStyle is obsolete. So you will have to change related MvcContrib code.
BTW, you can sign MvcContrib dlls without rebuilding them, for example with this tool: http://signer.codeplex.com/
I've got a project that I started in Turbo Delphi, which I recently updated to D2009, and I've noticed a bit of a quirk in the form designer. All the old forms have a Win98 style applied to them. The buttons are gray with sharp square edges, for example. But any new form I've created since the upgrade displays its controls in WinXP style. If I copy a control from an old form and paste it to a new one, the style changes. At runtime, all controls from all forms are shown in XP style.
Any idea what's causing my old forms to show in an old style? I've looked through the properties list, but nothing jumps out at me. But there's obviously something, and it's persistent because saving and reloading doesn't change it. Anyone know where this property is and how I can fix it?
You should enable run time themes.
Did you check?
Project | Options | Application | [ ] Enable Run Time Themes
looks at the uses clause in both a old form and a new one, there may be something diffrent. i know in delphi 7 you had to add xpman (or somerthing like that) to get the windows skin.
Have you checked the dfm files? Sometimes there is something there that is not shown in the propertylist.
Maybe you have a stray Ctl3D (sp?) setting in your dfm?
Well using D2007,
had the same issue on my run time packages. They may where create using D5 or D7.
To fix this issue: simple add a "XP Theme ManiFest" to your culprit package "res" file.
Example of a D2007 manifest:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
type="win32"
name="CodeGear RAD Studio"
version="11.0.2902.10471"
processorArchitecture="*"/>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
publicKeyToken="6595b64144ccf1df"
language="*"
processorArchitecture="*"/>
</dependentAssembly>
</dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="asInvoker"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>