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.
Related
In VCL I used TOpenPictureDialog for loading of image files because it's useful to see a preview when selecting from a long list of files. I also used it for loading my own binary file format by creating a class derived from TGraphic, overriding the load and draw functions and registering it with TPicture. Now I've moved to FMX and would like a similar preview, but there is no TOpenPictureDialog. My only alternative currently seems to be to create a custom form for loading these files, including the ability to browse folders, etc, which seems like a big job to replicate all the functionaly of TOpenPictureDialog. Before I do that I wonder if anyone knows of a pre-existing component that does this? I'd like to support Windows and OSX initially.
If I do end up making my own component, would it be easier to start from scratch or to derive from and extend TOpenDialog? It seems that TOpenDialog is just running the default Windows open dialog in Windows so it seems unlikely that I could do that.
This is one of the few things missing from FMX that is available in VCL.
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.
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.
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).
This is an odd behaviour by my D2006 as it happens sometimes only. I have a project I want to debug. The file I want to debug is named 'Main.pas'. I have another unrelated project with the same Unit name and sometimes the Debug prompt me the wrong Main file instead of the Main unit from the current project. This have happened to me with other files with the same name. I can't debug then as the debug keys don't work (they just don't do anything). Do you have experienced the same problem? How can I fix it?
Thanks.
Do you use relative paths?
If yes, I found out it helps to set the working directory to my projects directory y loading a file from my projects dir using File->Open. The navigating and loading apparantly sets the working dir, fixing the case where you THINK you are using paths relative to your project, but delphi interprets them relative to the working dir of the IDE.
Close all other tabs first though, to avoid mistakes. Since the delphi compiler is a dll, it interacts deeply with the IDE, and probably has access to which files are opened. (it can compile unsaved files!)
If not, it might a freak occurance, but still have the same origin. Developing a habit to first close other files (right click on tab->close all other), and fixate the working dir (with the load unit via file-Open workaround) might help.
I've the feeling the BDS series of IDEs seem to suffer from this more than the classic ones, but the problem existed in the classic ones too. Could be as simple as using more fancy opendialog options in BDS, increasing the chance on working dir change.
update Also only opening projects when no other projects are open helps. So always click the old project before opening the new, and don't click a project in the windows explorer if the IDE is open with another project loaded.
Delphi XE still suffers from this
I have run into that too, and now I tend to give files unique names, like instead of Main.pas, it might be ProjectNameMain.pas
Check your Library paths and Browsing paths in the Environment Options
Take a look at the output and DCU directories of the project. You're probably picking up an old DCU from a shared DCU directory. Clear out the DCUs and re-build.