I'm using Borland C++Builder 6.
TOpenDialog disappears while running my program.
What can be the reason?
Which property on the form\open dialog is responsible for this behavior?
Dialogs do not just disappear. Either it was intentionally closed, or it is probably hidden behind your main window. Unfortunately the VCL in BCB6 suffers from z-order issues, which were fixed in later versions. Try calling GetOpenFileName() directly so you can provide an owner window to avoid any z-order problems.
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.
Using FMX in C++ Builder 10.1 with update, it seems that doing the following can cause a problem on Macs. (I am using macOS Sierra, but it seems the problem occurred in previous OS versions as well.)
Create form using new operator.
Show form modally.
Form sets modal result > 0.
delete form from calling form.
where the close image on the modally displayed form has a TPopup with contextual help, where the TPopup's IsOpen value is set to false on a MouseLeave event.
It seems what is happening is that, sometimes, the form is being deleted before the TPopup code is processed because the mouse is no longer over the image. This causes an error and, on Macs, simply closes the program. The bug is fixed by removing the OnMouseLeave event from the button.
I do not have this problem when the target OS is Windows.
My first question is whether this is a bug (the image's OnMouseLeave event handler setting the TPopup's IsOpen=false should be processed properly when the form is closed), and my second is what approach should be used to handle this sort of problem?
We just moved our application from a MDI container to a single document interface. Our users are used to using a "Windows" menu in the MDI parent to show windows side by side. We want to train them to right click on the Windows taskbar and use the window management functions there.
With Delphi applications we noticed that the windows shell leaves room for the hidden "Application" window. So if I only have two windows open it will arrange room for three. The Application window is not really shown but there is space left for it.
This is made worse by the fact that we have two different applications. If they only have one window open in each application and want to show them side by side windows will actually try to account for 4 windows.
So instead of seeing two windows each taking 1/2 of the screen I see two windows that take up 1/4 of the desktop and the rest of the screen is open.
I found that adding a line to hide the application window as my application starts up will fix this problem.
ShowWindow(Application.Handle, SW_HIDE);
Edit in case someone does not read
down to the answer. Based on Craig's
answer below I am setting the windows
style to WS_EX_TOOLWINDOW instead of
hiding the window.
SetWindowLong(Application.Handle, GWL_EXSTYLE,
GetWindowLong(Application.Handle, GWL_EXSTYLE) or WS_EX_TOOLWINDOW);
My (original) questions is: Is this safe (hiding the application window)? I'm wondering if I may be breaking something else by hiding the Application window. Are there any side effect I need to be aware of? Is there a better way to solve this issue?
I'm using Delphi 2007. The issues seem to be consistent across Windows XP, Vista, and 7.
Update: Some of the answers seem to think the problem is with the Application forms icon being visible. That is not the case. I already have MainFormOnTaskbar set to true.
Also if you are testing this be aware that the Delphi IDE (only tested with 2007) makes things worse. Try this. Open the Delphi IDE and two instances of notepad. Minimize the IDE but have both notepads un-minimized. Right click on choose Show Windows Side by Side. You will see each notepad take up 1/3 of the screen. Close the IDE and choose Show Windows Side by Side again and each will take up 1/2 half of the screen.
In Delphi 2007 (and above) the Application Window does not show on TaskBar at all if
Application.MainFormOnTaskbar := True;
line is in a project file (*.dpr). For example
begin
Application.Initialize;
Application.MainFormOnTaskbar := True; // <--
Application.CreateForm(TForm7, Form7);
Application.CreateForm(TForm8, Form8);
Application.Run;
end.
That is default setting for new applications, but this line is absent if you ported an application from previous Delphi version - you should add this line manually.
As long as MainFormOnTaskBar is true, you can fix the problem by adding this to your DPR:
SetWindowLong(Application.Handle, GWL_EXSTYLE,
GetWindowLong(Application.Handle, GWL_EXSTYLE) or WS_EX_TOOLWINDOW);
Later versions of Delphi automatically include the WS_EX_TOOLWINDOW flag when they create the TApplication handle.
I'm still using Delphi 7, and I've been using this technique in combination with the 'WndParent:=GetDesktopWindow' trick to get a taskbar button for each window, somewhat like Microsoft Office started doing since some version (I guess XP?)
I believe at this is the way that applications minimize to the system tray.
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.