I've ran into a problem with "Vista Dialogs" in "Delphi 10 Seattle" yesterday. It seems to not work well with some VCL Styles.
This bug occured while using "Windows 10 Dark" as default style in my app.
So my immediate thought was that Vista Dialogs does not work with Custom VCL Styles, but when using "Windows" as a default style and using Windows 10 as OS the dialog works fine.
I've uploaded two pictures, one with the style applied showing the visual bug and one without it, working just fine.
Without "Windows 10 Dark" VCL Style applied
With "Windows 10 Dark" VCL Style applied
I've researched about this, this error is mentioned in other posts, but this bug is not what those posts are about...
Anybody understands why this happen? and how can I fix it?
The VCL Styles version included in RAD Studio only can style the classic dialogs, If you want full support for the New Dialogs you must use the VCL Styles Utils project.
Just install the library and add these units to your project.
uses
Vcl.Styles.Utils.Menus, //Popup and Shell Menus (class #32768)
Vcl.Styles.Utils.Forms, //dialogs box (class #32770)
Vcl.Styles.Utils.StdCtrls, //buttons, static, and so on
Vcl.Styles.Utils.ComCtrls, //SysTreeView32, SysListView32
Vcl.Styles.Utils.ScreenTips, //tooltips_class32 class
Vcl.Styles.Utils.SysControls,
Vcl.Styles.Utils.SysStyleHook;
Related
Following on from my previous questions (Delphi 6 TDateTimePicker Windows Visual Theme support via Manifest), we are updating a legacy application developed in Delphi 6 to support Windows Visual Themes (to freshen up the UI). We have included a Manifest and now also Mike Lischke's Windows XP Theme Manager (WXPTM) components, as per previous recommendations.
We can see three components on a new XP tab (palette) in Delphi, have included the path to the library's in our project and dropped the components onto one of the forms. The recompiled EXE is now displaying controls differently from prior to including WXPTM and it seems to have fixed a number of issues, so I am fairly certain (and hope) we have implemented WXPTM correctly.
However, we have some third-party component controls that are descendants of the standard ones, which we thought (hoped) would simply inherit from the replacement/updated controls in WXPTM. Unfortunately, it appears they do not, unless we have missed something out in the WXPTM implementation. Therefore, is it possible to make third-party controls inherit from the updated standard controls in WXPTM? Any tips, tricks, suggestions or advice to point us in the right direction would be greatly appreciated.
I just upgraded from Delphi 2009 to Delphi XE8. Doing so has changed the appearance of the buttons on the toolbar of my program.
When compiled with Delphi 2009, it looked like this:
But now with Delphi XE8, it looks like this:
It seems to me that this is related to the Down property. If a Down property of a button is true, then its background will be blue. If I click on the button then that will change the Down property to false and the button will lose the blue background.
Does anyone know what might be causing the blue background and how I can eliminate it?
I am on Windows 8.1.
Followup: David's answer that this is the default display for Windows 8.1 is correct. Checking other programs, I see they do this as well.
I wasn't expecting this to be the default because my program compiled with Delphi 2009 didn't do this. But as David also explained, that's because Delphi 2009 did not have built in theme support, but Delphi XE8 does. (It may have been added in Delphi XE2, but don't quote me on that)
David's mentioned the manifest as a possible cause. It wasn't in this case, but he alerted me that I may have multiple manifests and should check for it.
So the final answer to my question is that I don't want to eliminate the blue background. It is the Windows 8.1 default way of displaying Down buttons, and I want to display the native theme by my program.
Your D2009 program is not themed, but your XE8 program is themed. By that I mean that the XE8 includes an application manifest that specifies version 6 of comctl32. Your D2009 program does not include a manifest, or does not include that part of the manifest which requests comctl32 version 6.
The visual appearance of the XE8 program is the native platform appearance, and on the face of it, it would be normal to follow the platform's lead. So the option that I would opt for is to leave the appearance as the platform standard. That is go with the XE8 version.
However, to answer your question, you can revert to the old appearance by removing the comctl32 v6 part of the manifest. This will affect other parts of your program too. If you only want to disable themes for the toolbar, that can be achieved with SetWindowTheme.
Ever since upgrade to XE6 there seems to be a bug in the application menus when you use styles, best explained with these screenshots:
The 2nd screenshot has the "22" item Visible set to False
Delphi XE6 is using a outdated version of the VCL Styles Utils project to style the popup menus. This issue doesn't happen if the last version of the VCL Styles Utiles Project is used as replacement of the Embarcadero version. So as workaround you must download the VCL Styles Utils project from the repository, then add the units Vcl.Styles.Utils.Menus, Vcl.Styles.Utils.SysControls and Vcl.Styles.Utils.SysStyleHook to your project and finally comment or remove the Line (27) {$UNDEF UseVCLStyleUtilsMenu} in the Vcl.Styles.Utils.Menus unit.
I guess this is yet another reason why VCL styles are not ready to be really used.
TDateTimePicker control looks fine without VCL styles. Turn on any vcl style, and I get this appearance:
I can turn off the vcl styles for just this component type, by registering a style hook, but that looks really ugly.
This is on Delphi XE2 with update 4 installed.
Ideally, I hope there is a workaround, or some properties of the datetime picker, or some subclass of datetimepicker I could do to force the datetime picker to paint and theme correctly.
Note that normal comboboxes are theming correctly. Note that this reproduces easily in the most minimal sample project imaginable. Yes. It's Yet Another Styles bug.
Update It might be platform specific, related to Windows Common Controls versions on Windows Server 2008 R2 without Aero ("Desktop Experience" in Windows server component terms). It just occurred to me after other people cannot reproduce it, to try this on several different Windows machines. After I did that, I find that the problem only reproduces on Windows Server 2008 R2. Some of our customers use Windows Server 2008 R2. As you know a major reason for using VCL Styles is that it makes your app look the same regardless of what the windows theme is. However in the case above, the whole app themes properly, except the DateTimePicker control, which is themed incorrectly, and only on Windows Server 2008 R2. The same XE2-based demo app works fine on Windows 7.
Both the working and non-working systems have a ComCtl32.dll in the SysWow64 folder with version reading 5.82.7601.17514. However, clearly the native layout and appearance of these controls is different, when VCL themes are off, and this affects the skinning code, which fails.
Update2: Reported as a bug: QC Entry 106783
Ok, I just made a small change to the Vcl.Styles.DateTimePickers unit which is part of the vcl-styles-utils. To fix this issue when the "Windows Classic" theme is active.
Use this style hook in this way
uses
Vcl.Styles,
Vcl.Themes,
Vcl.Styles.DateTimePickers;
initialization
TStyleManager.Engine.RegisterStyleHook(TDateTimePicker, TDateTimePickerStyleHookFix);
And this will be the result.
I can confirm that when I install Desktop Experience, enable Themes and start the Themes service, this glitch goes away.
Okay here's my workaround code for now:
function DetectWin7Or2008R2ClassicTheme:Boolean;
begin
if ( Win32MajorVersion>=6 ) then
result := (not Themes.ThemeServices.ThemesEnabled) // and IsServerOs
else
result := false;
end;
// main form initialization section:
initialization
if DetectWin7Or2008R2ClassicTheme then
TStyleManager.Engine.RegisterStyleHook(TDateTimePicker, TStyleHook); {no theme!}
end.
It's clearly a wild corner-case. I expect to find more, and I'll come back and update this question when I find what else breaks on Windows Server 2008R2 or Windows 7, when the theme service is not running, which is what happens when you pick "Windows Classic Theme" on Win7, also.
Win7 x64, Delphi Xe2 update2
Prompt:
The new project, compile as x32, are applied visual (vcl) styles in the project options, by default one is chosen
On the form the button1 and WebBrowser1
In the button we write WebBrowser1.Navigate ('http://google.com');
We start, we press the button - in a browser we see a site google.com, all ок
We compile as x64, it is started ок, by button pressing we receive an error "float division on zerro".
Questions:
At all so (error)? And as with it to struggle? (in x64 mode)
How to apply visual style to strips of scrolling WebBrowser1? (in x32 mode)
:( a native component could not skin, but AlphaControls Skin system - work ok, and webbrowser scrolling lines skinned normal
p.s. update3 yet did not put
p.s.s. bad english: on
This can be done subclassing the TWebBrowser component and handling these events
OnDocumentComplete
OnNavigateComplete2
OnBeforeNavigate2
OnCommandStateChange
OnProgressChange
plus the WM_SIZE windows message.
The key is use the TScrollbar component and a Twincontrol as container to overlap the original webbrowser scrollbars.
I just wrote an article which explains in depth how this can be implemented Delphi Vcl Styles and TWebBrowser
VCL styles cannot be applied to TWebBrowser AFAIK. Its UI is controlled by Internet Explorer, not the VCL.