I have noticed a strange piece of behaviour when using MessageDlg and attempting to close my application via the Taskbar close all/group command.
My application is as follows:
There is a hidden main form which doesn't do anything other than handle some Windows Messages and pass them onto the child windows (if necessary).
Each child window has its parent set to the desktop (in order to get it displaying on the Taskbar).
Each child has an OnClose event which pops up a MessageDlg to prompt the user whether they want to save their session (if any content has been modified in anyway)
The issue seems to be it will continually close any windows that haven't been modified, however, when it hits a window that has been, 1 of 2 things are happening intermittently:
Regardless if I select "Yes/No" the Close All process seems to stop after that particular window is closed.
The dialog is not displayed and mrCancel is the result. Again the close all process stops after this window is closed.
A change I made was to use the WinAPI MessageBox function in replace of MessageDlg and this did seem to resolve the issue. However, I would really like to know why MessageDlg is acting like this?
My initial thought was when the dialog is being launched in the middle of the Close All perhaps the OS is sending a WM_CLOSE message to the dialog as it is technically part of the group (this would explain the dialog not appearing and defaulting to mrCancel as this is the equivalent of pressing the X). However, that doesn't explain why after I dismiss the dialog the Close All process does not continue to close any other windows in the group!
Any thoughts/idea's on this?
Windows doesn't send WM_CLOSE messages to these windows, it posts WM_SYSCOMMAND with the SC_CLOSE request. This in turn leads to the sending of WM_CLOSE messages if the standard Windows message box is used. If the MessageDlg() function is used instead, only the first posted WM_SYSCOMMAND leads to a WM_CLOSE, the others do not. It's hard to say for sure, but maybe this has something to do with the DisableTaskWindows() and EnableTaskWindows() calls that the VCL uses to "fake" modal dialogs. If you replace the Windows function with Application.MessageBox(), a wrapper that does use DisableTaskWindows() and EnableTaskWindows(), then it doesn't work either (which IMO supports this reasoning).
I think I can explain why switching from MessageDlg to MessageBox made things different. MessageDlg in turn calls the MessageDlgPosHelp which creates a Delphi form to look like the Windows MessageBox, and this form is called shown with ShowModal. This locks the entire application until it is closed.
MessageBox, on the other hand, defaults to MB_APPLMODAL which means you have to close it before the window it is attached to can be used. If you have nothing specified in the uFlags parameter then this is the default. This only prevents you from getting back to the window specified in the hwnd parameter, so other windows in your application are still accessible.
Related
I have a few applications and I call a ShowMessage('Complete!'); at the end of a long operation.
Most of the time, this works great, but every once in awhile, the Message Dialog will show up behind the main form.
Is there any way for me to ensure the ShowMessage will always be on top?
Thanks!
Call the Windows MessageBox() API instead and pass in the handle to the active form. Actually, my code uses Application.MainFormHandle all the time which I am therefore sure is a reasonable and simple approach.
This will have the benefit of being the system native dialog rather than the home-grown Delphi version. It supports clipboard operations also.
If you want to get very fancy then you can use the Vista task dialog, but that's much more complex and you clearly don't need it for such a simple dialog.
I have an application that uses tabs like the Chrome browser. Now I want to be able to open more forms and not be limited to only one form. These forms should act the same but if I close main form all forms are closed. How can I make all forms be equal, so no matter which form I close it only closes that form and not exit application before all forms are closed? Any ideas?
Image of my explorer
Kind Regards
Roy M Klever
It's not too hard to do this, though it starts getting complicated quickly depending on how complete you want it to be. Getting multiple modal dialogs to work independently is a ton of effort.
To start, you need to avoid Application.MainForm entirely. Always use Form := TMyForm.Create(Application) instead of Application.CreateForm(TMyForm, Form). The later sets MainForm and you never want that to happen.
To make things shut down properly you'll need to do something like this in your form's OnClose event handler:
if Screen.FormCount = 1 then
Application.Terminate;
CloseAction := caFree;
Application.Run relies on MainForm being assigned, so in your DPR replace that line with this loop:
repeat
try
Application.HandleMessage;
except
Application.HandleException(Application);
end;
until Application.Terminated;
There are a couple of ways to handle the taskbar entry.
Single taskbar entry: Set Application.MainFormOnTaskbar := False; and the hidden TApplication handle will be used. Clicking on the taskbar entry will bring all of the windows to the front. You'll need to override Application.OnMessage or add a TApplicationEvents component, and watch for WM_CLOSE with the Msg.Handle = Application.Handle`. In that case the user has right-clicked on the taskbar and selected Close, so you should close all the windows.
Multiple taskbar entries: Set Application.MainFormOntaskbar := True. Override your form's CreateParams method and set Params.WndParent := 0;. Each taskbar entry will control that form.
There are probably a few other gotchas, but that's the basics.
As I said, making ShowModal and TOpenDialog/TSaveDialog working independently, so it only affects its parent form and so multiple dialogs can be open at once, is a ton of work, and I can't really recommend it. If you're a masochist, here's the general steps:
Replace TCustomForm.ShowModal with a custom version. Among other things, that routine disables all the other windows in the application, so you need to replace the DisableTaskWindows/EnableTaskWindows calls with EnableWindow(Owner.Handle, False/True) to just disable the parent form. At this point you can open multiple dialogs, but they can only be closed in last-in, first-out order, because the calls end up being recursive. If that's fine, stop here.
There are two ways to work around that:
Rather than making ShowModal blocking, have StartModal and EndModal routines that have the first bit and last bit of ShowModal's code and call an OnShowModalDone event when the dialog is closed. This is kind of a pain to use, but is relatively easy to code and easy to make stable.
Use the Windows fiber routines to swap out the stack and start a new message loop. This approach is easy to use, because ShowModal is blocking, so you call it like normal. This is the approach we used in Beyond Compare. Don't do it. It's complicated to write, there will be stability issues for non-trivial applications because of incompatibilities with third party code (Windows global message hooks, TWebBrowser, .NET in shell extensions loaded by the browse dialog, etc), and if it's a cross-platform project, the Unix ucontext functions aren't safe to use either.
The common dialogs (TOpenDialog, TColorDialog, etc), have similar restrictions. To make them only disable the parent form you need to override TCommonDialog.TaskModalDialog and replace the DisableTaskWindows/EnableTaskWindows calls there too. They can't be made asynchronous like the regular Delphi dialogs above though, since they're blocking functions provided by Windows (GetOpenFileName, ChooseColor, etc). The only way to allow those to close in any order is to have each dialog run in a dedicated thread. Windows can handle most of the synchronization to do that, as long as you're careful about accessing the VCL objects, but it basically involves rewriting large portions of Dialogs.pas.
If you really want that,
1) use a small, maybe hidden, MainForm and launch just the first childform at startup.
2) launch separate applications instead of Windows in the same process. This is what later Office version use.
Here is a similar StackOverflow question:
Multiple app windows activation not working correctly
In my case I don't try to avoid the MainForm like Craig describes. Instead, I hide the main window and all of my real windows are other non-modal forms. I have been happy with how my application works, but Craig's approach may be simpler.
See my answer on the above question to see code samples for my approach and a few links with good background information.
The first form created in a Delphi application is treated as the main form and the application terminates when this form gets closed. The obvious solution is to have a first form that is not one that gets closed by the user but rather one that is not visible to the user and gets closed only when all other forms have been closed.
I have not tried this, but it should work.
This is too late to be an answer but I bumped into the same problem. The solution I opted for is to extract Application.ExeName and pass it to a function like createProcess or even shellExecute. So, now I have independent applications at the OS Level. I also needed different taskbar buttons for the different instances.
I am having trouble writing a program that I want to be active always.
I wrote code on keydown to do something, but when form1 is minimized or in tray keydown event does not response. How can I get my application to respond to keyboard events even when it is not in focus?
addition :
its window app , and lang is c#.NET ,
If I can assume that this program is for Windows, you cannot do that. Once you application window is closed, it will not raise KeyUp/KeyDown. Nearest to what you want is either hotkeys (to activate program once specific key is detected) or keyboard hook (if you wish to have overview of every key press).
However, what you will use depends on which exact scenario were you thinking about.
What is TApplication.Handle?
Where does it come from?
Why does it exist?
And most importantly: why do all forms have it as their parent window handle?
The Delphi help says:
TApplication.Handle
Provides access to the window handle
of the main form (window) of the
application.
property Handle: HWND;
Description
Use Handle when calling Windows API
functions that require a parent window
handle. For example, a DLL that
displays its own top-level pop-up
windows needs a parent window to
display its windows in the
application. Using the Handle property
makes such windows part of the
application, so that they are
minimized, restored, enabled and
disabled with the application.
If I focus on the words "the window handle of the main form of the application", and I take that to mean the window handle of the main form of the application, then I can compare:
"the window handle of the main form of the application", with
the window handle of the MainForm of the Application
but they are not the same:
Application.MainForm.Handle: 11473728
Application.Handle: 11079574
So what is Application.Handle?
Where does it come from?
What Windows® window handle is it?
If it is the Windows® window handle of the Application's MainForm, then why don't they match?
If it's not the window handle of the Application's MainForm, then what is it?
More importantly: Why is it the ultimate parent owner of every form?
And most important: Why does everything go haywire if i try to have a form be unparented unowned (so i it can appear on the TaskBar), or try to use something like IProgressDialog?
Really what I'm asking is: What is the design rationale that makes Application.Handle exist? If I can understand the why, the how should become obvious.
Understanding through a game of twenty questions:
In talking about the solution of making a window appear on the taskbar by making its owner null, Peter Below in 2000 said:
This can cause some problems with modal forms shown from
secondary forms.
If the user switches away from the app while a modal
form is up, and then back to the form that showed it, the modal form may
hide beneath the form. It is possible to deal with this by making sure
the modal form is parented [sic; he meant owned] to the form that showed it (using
params.WndParent as above)
But this is not possible with the standard
dialogs from the Dialogs unit and exceptions, which need more effort to
get them to work right (basically handling Application.OnActivate,
looking for modal forms parented to Application via GetLastActivePopup
and bringing them to the top of the Z-order via SetWindowPos).
Why does a modal form end up stuck behind other forms?
What mechanism normally brings a modal form to the front, and why is it not functional here?
Windows® is responsible for showing windows stacked. What has gone wrong that Windows® isn't showing the right windows?
He also talked about using the new Windows extended style that forces a window to appear on the taskbar (when the normal rules of making it un-owned is insufficient, impractical, or undesirable), by adding the WS_EX_APPWINDOW extended style:
procedure TForm2.CreateParams(var Params: TCreateParams);
begin
inherited CreateParams( params );
Params.ExStyle := Params.ExStyle or WS_EX_APPWINDOW;
end;
But then he cautions:
If you click on a secondary forms taskbar button while another app is
active this will still bring all the applications forms to front. If you
do not want that there is option
Who is bringing all the forms to the front when the form's owner is still Application.Handle. Is Application doing this? Why is it doing this? Rather than doing this, shouldn't it not be doing this? What is the downside of not doing this; I see the downside of doing it (system menu's don't work property, taskbar button thumbnails are inaccurate, Windows® shell cannot minimize windows.
In another post dealing with the Application, Mike Edenfield says that the parent window sends other window's their minimize, maximize and restore messages:
This will add the taskbar button for your form, but there are a few other minor details to
handle. Most obviously, your form still receives minimize/maximize that get sent to the parent
form (the main form of the application). In order to avoid this, you can install a message
handler for WM_SYSCOMMAND by adding a line such as:
procedure WMSysCommand(var Msg: TMessage); WM_SYSCOMMAND;
procedure TParentForm.WMSysCommand(var Msg: TMessage);
begin
if Msg.wParam = SC_MINIMIZE then
begin
// Send child windows message, don't
// send to windows with a taskbar button.
end;
end;
Note that this handler goes in the PARENT form of the one you want to behave independently of > the rest of the application, so as to avoid passing on the minimize message. You can add similar > code for SC_MAXIMIZE, SC_RESTORE, etc.
How is it that minimize/maximize/restore messages for my Windows® windows are not going to my window? Is this because messages destined for a window are sent, by Windows® to the window's owner? And in this case all the forms in a Delphi application are "owned" by Application? Does that not mean that making the owner null:
procedure TForm2.CreateParams(var Params: TCreateParams);
begin
inherited;
Params.WndParent := 0; //NULL
end;
will remove Application and it's window Handle from interfering with my form, and Windows should once again send me my minimize/maximize/restore messages?
Perhaps if we compared and contrasted now a "normal" Windows application does things, with how Borland initially designed Delphi applications to do things - with respect to this Application object and it's main loop.
what solution was the Application object solving?
What change was made with later versions of Delphi so that these same issues don't exist?
Did the change in later versions of Delphi not introduce other problems, that the initial Application design tried so hard to solve?
How can those newer applications still function without Application interfering with them?
Obviously Borland realized the flaw in their initial design. What was their initial design, what problem was it solving, what is the flaw, what was the re-design, and how does it solve the problem?
The reason for the application window has a bit of a sordid history. When developing Delphi 1, we knew we wanted to use "SDI" (windows scattered all over the desktop) ui model for the IDE. We also knew that Windows sucked (and still does) at that model. However we also noticed that Visual Basic at that time employed that model and it seemed to work well. Upon further examination, we found that VB used a special "hidden" parking window which was used as the "owner" (Windows blurs the notion of parent and owner at times, but the distinction is similar to VCL) for all the other visible windows.
This is how we solved the "problem" where the windows containing the main menu was rarely ever focused so processing Alt-F for the File menu simply wouldn't work. By using this central parking window as an intermediary, we could more easily keep track of and route messages to the appropriate windows.
This arrangement also solved another issue where normally multiple top level windows were entirely independent. By making the application handle the "owner" of all these windows, they would all behave in concert. For instance, you may have noticed that when you select any of the application windows, all the application windows move to the front and retain their z-order relative to each other. This would also make the application minimize and restore as a functional grouping.
That is a consequence of using this model. We could have manually done all this work to keep things straight, but the design philosophy was to not re-invent Windows, but to leverage it where we could. That is also why a TButton or a TEdit is really a Windows "User" BUTTON and EDIT window class and style, respectively.
As Windows evolved, that "SDI" model began to fall out of favor. In fact Windows itself began to become "hostile" to that style of application. Starting with Windows Vista and continuing to 7, the user shell doesn't seem to work well with an application using a parking window. So, we set out to shuffle things around in VCL to eliminate the parking window and move its function into the main form. This presented several "chicken and egg" problems whereby we need to have the parking window available early enough in the application initialization so that other windows can "attach" to it, but the main form itself may not be constructed soon enough. TApplication has to jump through a few hoops to get this to work, and there have been a few subtle edge cases that have caused issue, but most of the problems have been worked out. However, for any application you move forward, it will remain using the older parking window model.
All VCL apps have a "hidden" top level window called Application. This is created automatically on application startup. Amongst other things it is the main windows message handler for VCL - hence Application.ProcessMessages.
Having the apps top level window hidden does cause some strange things, noticeably the incomplete system menu that shows in the task bar, and incorrect thumb nail windows in Vista. Later versions of Delphi correct this.
However, not all windows must have it as a parent, Windows just tends to work better if it is.
However, any form created with Application.CreateForm will have it as the parent, and it will also be owned by the Application object. As they are owned, they will be freed once Application is freed. This happen behind the scenes in Forms.DoneApplication
From looking at the source in forms.pas (Delphi 2009), it appears that they create a "master" window in win32 GUI apps to allow calls to
TApplication.Minimize
TApplication.Restore
etc
It appears that messages passed to the Application.Handle are forwarded as appropriate to the MainForm, if it exists. This would allow the app to respond to minimize, etc if the main window has not been created. By modifying the project source you can create a Delphi app without a main window.
In this case, the TApplication methods will still work, even if you haven't created a main window. Not sure if I'm grasping all of the purposes, but I don't have time to go through all of the TApplication code.
Per your questions:
Where does it come from? It is the handle of a window created in TApplication.Create
What windows handle is it? a fake window that every GUI Delphi app requires as part of the TApplication abstraction
Is it the windows handle of the application's main form No
If its not the handle of application's main form then what is it? See above
more importantly: why is it the ultimate parent of every form? assuming you're right that its the ultimate parent, i assume that it is so because it makes it easy to find all of forms in your application (enumerating the children of this "master" form).
and most important: why does everything go haywire if i try to have a form be unparented I think because the hidden "master" form is getting system messages that it should pass on to its children and/or the main form, but can't find the unparented form.
Anyway, that's my take on it. You can probably learn more by looking at the TApplication declaration and code in forms.pas. The bottom line from what i see is it is a convenient abstraction.
I've got a timer running in my Delphi MDI application and I'd like to use it to pop up a message if something changes in the background. But I don't want that message to pop up when the the application has a modal dialog in the foreground because the user couldn't do anything about it.
So what I'd like to know is how can I check for the existence of a modal dialog in my application?
You could try with this code:
var
ActForm: TCustomForm;
begin
ActForm := Screen.ActiveForm;
if (ActForm = nil) or not (fsModal in ActForm.FormState) then begin
end;
end;
I tested with Delphi 4, works for me.
[EDIT]: But you should really think about whether popping up a form and stealing focus is a good idea. It depends on your application, but if a user is currently entering something into an edit field, or doing something with the mouse, then this might break their workflow.
Since Delphi 2005 you have a ModalLevel property on TApplication. It counts the number of Modal forms opened in the application.
Perhaps the solution is to actually pop up a hint which doesn't steal focus. A clickable hint somewhere visible, but not too invasive. Thus, if the user wants to take action they can, or they can finish off what they were doing, then take action. Or perhaps ignore it altogether.
use AnyPopup() function
About GetLastActivePopup(). It may return value is the same as the hWnd parameter when
The window identified by hWnd was most recently active.
The window identified by hWnd does not own any pop-up windows.
The window identifies by hWnd is not a top-level window, or it is owned by another window.
Today user histrio correctly answered in another thread that just monitoring modal Delphi forms is not enough; Windows can also have modal dialogs.
His answer in another thread shows you how to check for that.
--jeroen