I've noticed that when I use TRibbon control that comes with Delphi 2010, it works flawlessly on my Windows 7 system. However, the application has some weird painting issues on a Windows XP system with the "classic theme" (I haven't tried the playschool theme).
I know there are other Ribbon components available from DevExpress and TMS Software, however purchasing a 3rd party control is not an option for this project.
Has anyone had this issue, or know of a solution?
Most likely because Windows 7 uses "Desktop Compositing", which essentially means that a component is drawn to an off-screen bitmap and then copied onto the display. In XP, a component typically draws directly onto the display (which can cause flicker if the component first erases what's there and draws over the "clean slate").
Delphi supports double-buffering, which accomplishes the same thing. If you set the ribbon's DoubleBuffered property to True (in code, since it's not published) then that should avoid the flicker (at the cost of extra memory allocated and moved around when drawing)--I should say, however, that I haven't actually tried it with TRibbon.
Note that there is no additional overhead when running on Windows 7 (or Vista, for that matter) if you set DoubleBuffered to True. The VCL has code the skips the off-screen bitmap business when running on a version of Windows that does desktop compositing.
Most likely this is a bug in the TRibbon code, the Microsoft ribbon renders perfect in both XP and Win7.
If you change your XP theme does the Minimise button shown in the image change to reflect your theme change? If this is the case the Ribbon code has probably been optimised for Vista and 7 and not been developed to run perfectly under XP.
You cant really resolve it unless you can modify the TRibbon code.
Related
I recently got a new development computer with again 2 monitors, but unfortunate it has windows 10.
Now I also have some tools still developed in Delphi 7 and they work but with one annoying problem.
When I start an Delphi 7 application the icon on the taskbar does not move to the second monitor.
The taskbar is setup to show icons on the taskbar of the monitor they are open. This works for all applications, except for the Delphi 7 applications.
The icon always stays on the primary monitor.
I have the source available, so I wonder is there something I have to put into the source code, or setup some property, to get this working ?
Googling this bring up lots of cases where the form does not moves to the second monitor, but I did not find anything about the icon on the taskbar.
This is because the window handle associated with the taskbar button is the window handle owned by the Application object rather than the window handle of your main form.
In later versions of Delphi you would write Application.MainFormOnTaskBar := True in your .dpr file and that would change behaviour so that the taskbar button was associated with your main form instead. I believe that MainFormOnTaskBar was introduced in Delphi 2007.
Migrating to a modern version of Delphi is the ideal way to solve the problem. If you cannot do that then you'll need to hack your way around the VCL code to ensure that the main form's window handle is the one associated with the taskbar button. That's not likely to be an easy job. Fundamentally, you are paying the price for continuing to develop with tools that are long out of date.
As Remy points out there isn't much hacking required to do the bare minimum. Change the window style of the Application window to remove the WS_EX_APPWINDOW style, and have the main form override the CreateParams method to set its owner window to NULL, i.e. Params.WndParent := 0.
I suspect that the behaviour will not be quite as smooth as you'd get with a modern VCL app. For instance, the VCL has been modified to reduce the amount of window recreation it does which is more important now that the main window is associated with the taskbar button.
I created the manifest file for my Delphi 6 application so it can display controls according to the theme defined by Windows (controls 6.0). Everything looks fine, except TBitBtn component, which is displayed using the legacy theme:
The behavior is the same on Windows XP and Windows 7, regardless of the current theme, even when no image is assigned to the TBitBtn component.
Now, when I put a regular TButton component on a form, it displays OK. If I then programmatically set an image to this button in runtime (using SendMessage(Handle, BM_SETIMAGE, IMAGE_ICON, LPARAM(Icon))), it immediately reverts its style to the legacy one.
Is there a way to either make TBitBtn use a proper style, or to display glyph on a regular TButton without reverting to the legacy one in Delphi 6?
In Delphi 6 it is not enough just to add the comctl32 v6 manifest. You also need to modify the VCL to be theme aware. The TBitBtn control is a VCL implemented control that, in its Delphi 6 incarnation, does not know anything about XP themes.
The standard way to deal with this is to add some third party software that performs the magic. That's the XP theme manager from Mike Lischke.
Here's a screenshot from a Delphi 6 application that includes the theme manager:
Standard Delphi controls (panels, buttons etc.) all have this bevel effect (white line on top and on the left) that gives them a 3D feel but today it makes them look old fashioned.
Is there a way to remove this "3D look" at least in Delphi 7?
Some controls have a Ctl3D property that you can turn off.
For a TPanel, you can also turn off its Bevel... properties.
What you really should do instead is enable Visual Styles in your app so it has a themed look on Windows XP and later. Delphi 7 did not natively support Visual Styles, but you can use Mike Lischke's XP Theme Manager component to handle that (it was incorporated directly into later VCL versions).
I`m using Delphi XE3. When using the custom styles (e.g. Carbon) that are available since Delphi XE2, there is a visible white flickering when moving the mouse over the borders of the TComboBoxEx control (MouseExit/Enter).
Steps to reproduce: Create a new VCL Forms app, drop a TComboBoxEx on the form, select e.g. Carbon in project options --> Application\Appearance and start the application
Is this a known problem/bug and is any solution known?
Thank you
This Border flicker issue is not the product of using Delphi VCL Styles.
(The same problem can be observed without using VCL styles)
The culprit here is the Desktop Window Manager which is an essential part of Windows Visual Styles and Themes.
The reason why you are seeing this issue and others may not, is because you have at some point changed the default Windows Theme (aero theme) or you've changed a specific Visual effect property of your selected theme.
You perhaps also have intentionally or unintentionally disabled the Desktop Window Manager since it runs as a Windows service.
To be more exact, the issue is resolved if you enable the Desktop composition feature.
This feature is only available in Aero themes(default) but not in Basic or Classic, tho sometimes it can appear to be available even when it is not.
Control Panel --> System --> Advanced System Settings --> Advanced --> Performance Settings --> Visual Effects
When desktop composition is enabled, individual windows no longer draw
directly to the screen or primary display device as they did in
previous versions of Windows. Instead, their drawing is redirected to
off-screen surfaces in video memory, which are then rendered into a
desktop image and presented on the display.
As you might have guessed, the functionality of this function is to basically act as a Buffer which in a very neat way explains the border flickering when this option is turned off.
Important Fact
Desktop composition feature can only be enabled if your current theme is an Aero theme and using Windows Visual Styles.(It is by default enabled for every Aero Theme)
Visual Styles are enabled by default in Aero Themes, you can check that it is enabled by making sure that the Use Visual Styles on Windows feature is enabled in the Performance Settings. When the Classic or Basic Themes are in effect the desktop composition feature is never in play and cannot be enabled. (Classic theme has been deprecated since Windows 8)
Sometimes in Windows 7, the Desktop composition feature can show itself in the Performance Options even when using a Basic or Classic Theme but do not be fooled, this is an internal bug.
Steps to reproduce this bug :
Start With default Windows Aero Theme
Go into Performance Settings as described above
Uncheck the Desktop composition from the list
Mouse over the border of TComboBoxEx, it should now be flickering as
you enter/leave.
But what happens if I uncheck Use Visual Styles on Windows checkbox? Why does this solve the flickering issue?
This will cause the Desktop Window Manager(DWM) to disable themes all together for all Windows Controls. What this means is that controls will be drawn using an older rendering style as oppose to using the newer Aero rendering style.
You can turn off Visual Styles for individual controls without turning it off globally with the following method SetWindowTheme(Handle, nil, nil)
This is also why the flickering issue for TComboBoxEx border is resolved when Visual Styles are disabled.
It's also worth mentioning that since Windows 8 you cannot disable Visual Styles anymore because as I said the Classic theme is deprecated.
Regarding the solution, I don't think you've got much of a choice really. Given how much freedom is left to the user when it comes to modifying the visual effects of Windows themes, this sort of thing is bound to happen. At least you can be certain that this issue does not happen on the default Windows Theme.
I have imported ActiveX controls before and were able to use them same as regular VCL controls. Every now and again I bump into a control that imports fine but doesn't show up at run-time and only show a little block in the designer.
The latest one is an ActiveX wrapper for the Scintilla editor and it shows me a grey block 100 pixels wide and 41 pixels high with the control icon on it. At run-time there's nothing, so it baiscally acts like a non-visual component even though it's supposed to be an edit control.
My questions are:
Has anyone else seen this?
Is this a known issue with Delphi's ActiveX support, or is it more likely an issue with the control itself?
I have never seen this behavior, I suspect it's a problem with the control.