We have a Delphi project which is DPI-aware. We've achieved this, amongst other things, by including a manifest in the executable. This all works fine, the project scales nicely according to the DPI settings.
Recently we've begun translating our product, for which we are using Sisulizer. This tool has been configured to generate a resource DLL. The manifest is copied to the resource DLL by Sisulizer but is not translated. So the translations are working fine too :)
However, the translated project is no longer fully DPI-aware. MessageBoxes (from the Windows API) are still DPI-aware but the rest of the project no longer scales. The untranslated project is still DPI-aware.
Issue has been resolved. The manifest was not the problem, it was an option in the Sisulizer-project: "Form scaling" was set to "Disable scaling", which caused the dfm to be changed in the resource DLL ("Scaled=False" was added). Changing it to "Ignore" resolved the issue.
When changing language from the GUI (so Screen.FormCount > 0) the scaling was not automatically set to the correct DPI. Or in other words: the forms are streamed from the resource DLL in their design-time state. We have fixed this by recording the scale factor for each form prior to switching to another language. Once the language has been changed (and all the forms have been translated) we re-apply the scale factor to the forms so everything shows up as expected.
Related
My delphi application looks nice and pretty in the editor, but when compiled it's seemed to being using super old rendering for the buttons and stuff. I thought my compiled applications used to look pretty like the editor. What could I have screwed up for this to be happening?
One suspicion: a while back I was messing with manifests on a different app that needed to find the actual program files directory. Could I have screwed up my delphi project trying too hard for that? This project is set to use runtime themes.
The top is in the editor, the bottom is the compiled version
Your program is being rendered without themes. Possible causes for that:
Your executable has no manifest.
Your executable has a manifest, but it does not specify v6 comctl32.
Your manifest does specify v6 comctl32 but the process is using an external compatibility mode.
Your program disables visual styles in code. For example with a call to SetThemeAppProperties.
Your program uses activation contexts to activate a different manifest from that linked to the executable.
These possibilities get progressively more far-fetched. Most likely you've somehow fluffed your manifest. That's easy to check with a resource editor.
I started my first iOS application in Firemonkey, and the compiler immediately started complaining "File not found unit1.lfm". There is no such file in my project, and my application has no main form, just a unit with a form referenced...
{$R *.lfm}
What's wrong?
I'm asking/answering this Q/A style. I faced this issue and quickly knew what was wrong, and a lot of other people are bound to face this.
This is because the IDE's form designer for iOS (and all Firemonkey) applications requires that you have the "Embedded Designer" enabled. By default, this is enabled in these later versions of Delphi which have the option. However, many people disable this to mimic the old fashioned Delphi versions (where the forms are floating separate from everything else). These forms cannot be shown as their own windows in Delphi XE2, so they need to be designed in the embedded designer.
To fix this, go to "Tools > Options > VCL Designer" and then check the option "Embedded Designer". This will require you to restart your IDE for it to take effect.
Unfortunately, you will have to delete any saved files and create your project again. The links are broken after you've started a new project with this disabled. (technically it can be recovered, but it's easier to start over anyway)
In a legacy application (created in Delphi 6 under WinXP in 32-bit, recently ported to Delphi XE2 under Win7 in 64-bit) at design time, the standard controls look "modern", with color gradients etc. In run-time though, they look just like an old Win95 version.
That would not bother me much if, in particular, the default colors in TPageControl and TTabControl wouldn't make it really difficult to tell which tab is currently selected.
So my questions are:
What could make the theme not active at run time?
Is it possible to easily (e.g. through IDE configuration) make the design time look like the run time?
Note:
In the project options, I enabled runtime themes for each existing target. It didn't help.
I also tried to enable GlassFrame in the forms containing those controls. Unfortunately, the runtime look and feel stayed unthemed.
This application is built on a lot of in-house and external code that
I don't master (just a dwarf standing on shoulders of giants),
but whose source are available to me. Suspecting that some
instruction would disable themes at application startup, I looked for
some keywords like "Theme", "Skin", "TStyleManager", "SetWindowTheme"
hoping to solve this by myself. I could not find anything significant (to me, at least).
I tried to skin a small application as a test, using infos from
Question
Delphi XE2 VCL styles tutorial - how to change the style at runtime,
and it worked perfectly.
Skinning my application is not my goal. I just would like to be able to visually tune some GUI elements at design time, and it is easier if design and run time look alike.
It turns out that removing the line "{$R *.res}" in the dpr file had made the themes unavailable.
Under D6, I disabled version information in the project and replaced "{$R *.res}" with "{$R 'myApp.res' 'myApp.rc'}", to use my own rc file to have the version information in a separate, easy to edit file, and not to be forced to go through the project options.
Under XE2, that did not work anymore because the resource would often be overwritten (or not taken into account, I'm not quite sure) by Delphi during the build. I had to rename the rc file so that it does not match the application name, thus replacing "{$R 'myApp.res' 'myApp.rc'}" with "{$R 'myApp_rc.res' 'myApp_rc.rc'}".
Putting the "{$R *.res}" again (along with "{$R 'myApp.res' 'myApp.rc'}") seems to make things right with themes and not break the version information.
Thank you Brian for having me look in the good direction.
In my experience this is often due to project differences between DEBUG mode (used by default when in the IDE) and RELEASE mode. Open your project options and scroll to application (where themes styles and icon are defined). Notice that the platform and build option combo at the top holds separate values for each setting and I expect you will find that your DEBUG build config has runtime themes enabled but RELEASE does not.
I've been banging my head against this for the past two days and can't seem to make any progress...
Pretty much from one moment to the next, Delphi XE2 won't properly compile one of my projects any more. That is, it actually compiles without errors but at runtime I get resource not found errors for what is essentially the main "form" (it's actually a data module in this case). I have already reverted to older versions of the project from source control that I know were definitely working alright but to no avail. Judging by that it seems it must be something inside Delphi/the IDE itself rather than in the project source. However, I have also not been able to reproduce the issue with a simple test project nor with any other real-life projects... It only happens with this one.
Another strange thing is that when I look at the produced binary with XN Resource Explorer everything looks as it should: The form resource mentioned in the error message is actually there and intact...
At some point I was suspecting this might be caused by a bug in one of the experts I have installed in my IDE (e.g. Uwe's platform and OI experts and VersionInsightPlus, Andreas' IDEFixPack and DDevExtensions, GExperts) but even after disabling all these the problem persisted.
Unfortunately, I am unable to track down exactly when this started to happen as I had been working for some time without actually running the binary, fixing compiler warnings and errors for the x64-target, adjusting build events for updated third-party tools (localization and license protection) and such things...
Has anyone else ever seen anything like this happen? Any more ideas on how to pin this down?
Some more details about the project:
It is an addin for Outlook built using the Add-In-Express framework (i.e. a COM-DLL).
The "main form" is a TDataModule-descendant - we also inserted our own ancestor-class into the hierarchy, i.e. the "addin module" is not directly inheriting from TadxCOMAddInModule - the resources of the custom ancestor forms also appear to be present and intact in the output binary when checking with a resource viewer.
Built without runtime packages for the Win32 and Win64 platforms.
Let me know if you think I missed to mention any other potentially relevant details.
Update:
I have now transferred the sources in question onto a different machine. Interestingly, the DLL I compiled there did not exhibit the problem - on that machine that is... when I transfered it back to the original machine and I tried to call it, the error was back (to stress this: this was the exact same DLL producing a EResNotFound on one machine but not on the other. Of course, once I had discovered this, I also performed the reverse test and lo and behold, the DLL compiled on the original machine works without errors on the other machine...
Seems this might not be a Delphi problem after all... but what is it then?
Differences between the two machines:
Machine 1 (the one were the problem occurs): Windows 7 Ultimate English 64bit with Delphi XE2 Update 4
Machine 2: Windows 7 Professional German 32bit with Delphi XE2 Update 3
On a third machine that is almost identical to the first except that it doesn't have Delphi on it, DLLs produced by both machines work flawlessly.
I am a bit surprised to see your question here. :)
We faced a number of serious issues with recent Update 4 for Delphi XE2. Though we have never run into or been reported of the "resource not found" error, I think this update might be one of the causes. Have you installed it?
One more thing that comes to my mind is images that you use for your Office controls (command bar and ribbon). Probably they got broken somehow, the run-time code cannot load them and reports this error.
Anyway, as you understand, these are just my guesses, if you need our assistance with your office add-in please contact Add-in Express support service, we will try to help.
Update: Seems I was a bit too quick, drawing conclusions. Apparently the Sisulizer solution is also supposed to perform a fallback to the main resource block. I have now taken this issue to the product forum and will report back here, once this is resolved.
Alright, mystery solved at last:
I had turned off the option to "Copy all resources" in Sisulizer in an attempt to reduce the size of the produced resource DLLs and then had forgotten about it...
I hadn't fully realized the implications of the standard Delphi resource DLL approach to localization on which Sisulizer "piggybacks" - especially that it was an all-or-nothing deal: Our previous translation solution implemented a fallback-mechanism that would read any resources not found in the external resource DLL from the host binary instead. This does not appear to be the case with Sisulizer - at least not out of the box... thus, any resource that's not contained in the localized resource DLL does not exist as far as the application is concerned.
I also didn't realize that the mere existence of a file with the same base name as the main binary and an extension matching the current system's default locale (such as .EN or .DE) would automatically cause the VCL to load it...
The machines that did not exhibit the error either still had the older, larger (=complete) resource DLLs on them, or no resource DLLs at all.
Every Delphi 7 developer knows that if he compile a application on Delphi 7, the style will be as Windows 2000 applications, but there is any method to make this better as the application can have the default theme of the Windows version, as C++ and C# applications?
Try adding the TXPManifest component to the main form of your application. located in the Win32 Tab.
The TXPManifest component has no methods or properties. All it does is include the XPMan unit in your project. This in turn causes a certain resource file to be included in your project's executable file. The resource includes a manifest - a small piece of XML that contains information about the application you are writing as well as information concerning the version of the comctl32.dll to use.
Alternatively add your own manifest resource manually - which allows you to tap into the even newer Windows 7 features, if you can be bothered to fathom out the syntax. See this link for more info but ignore the bit about enabling runtime themes as this doesn't exist in D7 (I don't think).