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 a largish Delphi 6 app that I have ported to Delphi XE3. At one point the main form launches another non-modal form. Sometimes (say 50%) after a second or two the newly created form moves behind the main form. Even thought it is now at the back, the newly created form still has focus so there are no activate/deactivate events. There are a few Timer controls and I have disabled them. It still happens.
I can accept my code is doing this -- but how can I find out what is happening? Is there a way to intercept when then new form moves to the back?
Just to be clear: I want both forms to be used separately. Any of them can appear behind the other. What is happening at the moment is that the z-order seems to be changing.
I have found the answer to this. I discovered I had added a CreateParams override that did this:
// make a taskbar window
inherited CreateParams( params );
params.ExStyle := params.ExStyle or WS_EX_APPWINDOW;
params.WndParent := GetDesktopwindow; // this line caused the problem
Commenting the WndParent solved it. The effect is bizarre though. It is as if there is a timer that goes off about a second after any key or mouse event that forces the window behind others. Thanks to David Heffernan whose comments about stepping CreateParam made me notice it.
Hello and thanks as always,
I have a problem to minimize a MDIChild form in an MDI application MDIChild simple
when I call the child form appears active and downplay it, but when I open more forms and I minimize, these are not active, always active appears to minimize the first form, I realized that the message WM_MDIACTIVATE not work, maybe I should overwrite any procedure window?
Thanks a lot!
I'm attempting to run this in a timer:
Application.Minimize;
ShowWindow( Application.handle, SW_HIDE );
It's been in the code forever and we just discovered that it doesn't work when you have a popupmenu active, it doesn't minimize the MDI parent window.
I figure if I can close the popup menu before running this code, then I'll be ok. Problem is, this code is in an MDI Parent and I have no idea where the current popup menu is. It doesn't matter if it's part of another form's tool bar, this forms tool bar, the product of a right click or that seemingly pointless key next to the space bar.
So, is there a way to hide the active popup menu in my entire program?
Also, if there's a better hunk of code than what I'm using to minimize that'll circumvent this issue, that'd be awesome info too.
To close a popup menu you can use
if GetCapture <> 0 then
SendMessage(GetCapture, WM_CANCELMODE, 0, 0);
in your code before you try to minimize the form.
I have a "username" TEdit on a Delphi 2006 login form. When the application starts up the user is asked to enter the username. The TEdit gets focus and the caret is placed in its horizontal center for some reason. As soon as anything is typed the caret is left aligned again and everything looks normal.
It is also strange that it wasn't always like this. This behaviour suddenly started a few years ago (I believe we still used Delphi 6 at that time). Any idea what might be causing this?
Additional info (has been asked for):
The problem is widespread: D2006 and D6 (I believe), 5 or 6 Delphi instances on as much computers, all applications using that login form. The effect is limited to the form however, it does not occur on other TEdits.
The TEdit is not filled with spaces (that would be strange to do in the first place).
More info (Nov 13):
The caret is not centered exactly, it is almost centered.
Currently it seems to occur in a DLL only. The same login dialog is used in regular executables and does not show the problem there (although I believe it did at some time).
The edit field is a password edit, the OnChange handler sets an integer field of that form only, there are no other event handlers on that edit field.
I added another plain TEdit, which is also the ActiveControl so that it has focus when the form shows (as it was with the password edit). I also removed the default text "Edit1". Now the issue is present in that TEdit in the same way.
The "centered" caret goes back to normal if either a character is entered or if I tab through the controls - when I come back to the TEdit it looks normal. This was the same with the password edit.
I had also the same problem in Delphi 2007,
with a TEdit placed in a modal form called by double-clicking in a Grid.
I made some tests launching the same Form from a TSpeedButton.
I noticed that the problem with the TEdit appears only when the grid is focused.
after more tests the problem appears to be a bug in the VCL.
in TCustomGrid.paint there is a Call of SetCaretPos, even if the grid is not on an active Form.
../..
Focused := IsActiveControl;
if Focused and (CurRow = Row) and (CurCol = Col) then
begin
SetCaretPos(Where.Left, Where.Top);
Include(DrawState, gdFocused);
end;
../..
the code above is from TCustomGrid.paint in Grids.pas
in this code, Focused is set to true if the grid is the "activeControl" of the parent form, the code don't take into account if the form is active or not.
then, if the grid need to be repaint, setCaretPos is called with grid coordinates, causing the bug mentioned in the question.
The bug is very difficult to notice because, most of the times, the caret simply disappear from the active form instead of blinking near the middle of a TEdit.
steps to reproduce the bug :
start new VCL form app.
add TStringGrid into it.
add a second form to the app with just a TEdit in it.
return in main form (unit1) and call form2.showmodal from the grid DblClick event.
that's all : you can launch the application and double click on a grid cell.
if you drag the modal form away of the main form, the grid will need to be repaint, then causing the caret to disappear from the modal form (or to appear in the middle of the TEdit if you are very lucky)
So, I think a fix is needed in Grids.pas.
in the excerpt of grid.pas above, I suggest replacing the call of the function IsActiveControl by a call of a new function called IsFocusedControl :
// new function introduced to fix a bug
// this function is a duplicate of the function IsActiveControl
// with a minor modification (see comment)
function TCustomGrid.IsFocusedControl: Boolean;
var
H: Hwnd;
ParentForm: TCustomForm;
begin
Result := False;
ParentForm := GetParentForm(Self);
if Assigned(ParentForm) then
begin
if (ParentForm.ActiveControl = Self) then
//Result := True; // removed by DamienD
Result := ParentForm.Active; // added by DamienD
end
else
begin
H := GetFocus;
while IsWindow(H) and (Result = False) do
begin
if H = WindowHandle then
Result := True
else
H := GetParent(H);
end;
end;
end;
this fix (made in Delphi2007) worked well for me, but is not garanteed.
(also, do not modify directly units of the VCL).
Just a few additional questions:
Is this problem on one pc or on more pc's?
Does it occur on one application or on all applications?
Does it happen only on your Delphi applications or on all applications?
If it is only on one pc, I think it is a strange registry setting. If its on more pc's but you only have one delphi development pc, it could still be a registry setting. But there are other possibilities.
You could try some tests:
Create an simple app on the dev pc and run it on another. Does this show the effect.
Use an app that is created by Delphi but build on another pc that does not show the effect, and run it on the dev pc, does this show the effect?
I really think this is a registry setting. According to the information you gave me, it happened since Delphi 6 and is still happening.
It also can be a locale setting but then it has to happen in more programs.
Edit:
Thanks for the extra info.
So it looks like the problem can be isolated to a single form. But it occurs on all pc's.
What you can do, is delete the edit, and re-add a new one. This saves searching for weird property values.
Are there events hooked on the TEdit that can possible explain the effects?
What property values are set? (But I prefer a look at the dfm and the code, because then I'm possible able to reproduce the effect.)
Are you sure it is a simple TEdit? It might be initialized with a few spaces instead of an empty string. The onChange handler then might just strip spaces as soon as you start typing.
A TEdit extension might have text alignment set on centered instead of left, and set text alignment only on onChange.
[edit]
Please show the event handlers of the TEdit.
I've also noticed this behaviour in richedits.
One place in our app is a double click on a grid which displays another screen containing a RichEdit. The caret always seems to appear in the Richedit in the same place as the double click on the grid occured, ie if the dblclick was on the 3rd line of the grid, the caret will appear ~3 lines down on the edit. As soon as a key is pressed, the caret resets to the correct position of top left.
Its not limited to a certain form or pc as it happens on all developers machines and also on clients machines.
The app was originally developed in Delphi 5, but the problem didn't occur (or wasn't noticed) until we moved to D2006.
Its not a particularily big problem, just... irritating.
Another workaround:
Before showing the second form, prevent the grid on the first form doing Paint action. Code snippet as below.
Gird.BeginUpdate;
try
//Show the second form here
finally
Grid.EndUpdate;
end;