I'm working on a C++Builder application that uses an ActiveX control to perform some background work. If I run the app visibly, it works fine. But when when I run it invisibly (done by setting Application->ShowMainForm = false during startup), the ActiveX control does not behave the same. ActiveX methods that return immediately work fine, but a method that does background work does not work, no progress is made.
What can be done to make ActiveX controls behave normally, and let them perform background tasks, when the application is invisible?
As a test, I have created a small C# .NET project in Visual Studio, and there the same ActiveX control works fine in invisible mode (but not in C++Builder).
Calling HandleNeeded() on the ActiveX control in the form constructor fixed the problem.
TForm1::TForm1()
{
control1->HandleNeeded();
}
Apparently, some ActiveX controls need a window handle to function properly, and this handle is not created automatically when it is hidden.
Related
For an Application I need the user to be disabled to click on a specific window, while he is still able to use a window, which is in front of the other window.
In Delphi, this works perfectly fine with
ExampleForm.Enabled:= False;
but in Firemonkey it seems as if the enabled property does'n exist anymore. As well, it would be really helpful if it could disable the keyboard inputs etc. as well. I would really appreciate a solution for that problem, thanks for your time!
PS: I use the Delphi 10.3 Version
In Firemonkey, you're typically expected to implement all of your controls inside of a TLayout or one of its descendants such as TGridLayout. As long as all of your controls are in there, you can disable its Enabled property. The form is really just a container and not the same type of control in FMX as it is in VCL.
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 have ported a control heavy application in firemonkey which I have worked upon with DXScene for little over 2 years now. The sheer number of visual controls updating on every UI change warranted the BeginUpdate-EndUpdate methods prefixed and suffixed respectively in all UI update methods.
After porting, the firemonkey engine behaves erratically to these methods.
Sometimes the new controls get built but not updated with contents.
Sometimes they don't even show and a forced form minimize-maximize gets them shown.
And all the time the form gets behind all the other open windows.
Is it still advisable to use these or an alternative has been introduced in FMX?
Have you seen this?
I have a little utility application (for easy load / test xml generation from CDS and/or DBGo), and I had put some buttons (the poorest button of all, TButton) to trigger some actions.
I never paid attention to appearance, because I'm the only one that uses it. So today I added a new button, and they appeared different from the others in designer - but not when running. It's just an copy and paste process (change the button name, caption and event - the rest is equal to the origin).
When I looked the other buttons have an grey gradient and round corners, the button I copied and pasted not (just a bare rectangle). When running all buttons where just bare rectangles.
So I discovered that on designer, W7 and delphi are applying themes. On running, they are obeying the Project/Options/Application/Enable runtime themes flag.
This is annoying. There's a way to make Delphi doing that obeying the project options flag on forms designer?
(Or even manually if is not possible to automate that)?
EDIT:
The toolbars on the form are from CNWizards ;-)
EDIT II:
Apart of disabling themes for the IDE executable, all buttons get themed equally if the form (or project) is reloaded. But it's really weird.
If you want to enable/disable themes in the IDE, then open the properties of bds.exe, select the 'Compatibility' tab, and make sure that the 'Disable visual themes' checkbox is unchecked/checked.
Programs that you run from the IDE will inherit the compatibility settings of the IDE.
Delphi IDE itself is an application and the way the designer draw the form is using the setting for the IDE application (delphi32.exe or bds.exe's compatibility settings) so the answer is no. The default behaviour is different between IDE versions, for eg. the opposite behaviour (not drawing themed) happened in past.
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.