I'm experiencing some troubles with JclMAPI. Currently I'm using JCL 2.6 Build 5178 with Delphi XE3.
The main form of my application is a MDIForm which handles different MDIChild forms. From one of these I can display a modal form and from it I call the JclSimpleBringUpSendMailDialog assigning the ParentWND parameter with the modal form handle.
Normally this method opens the email message window in front of the modal form.
My problem is that sometimes the e-mail message window goes underneath the application mainForm and I'm not able to bring it to the front anymore.
So the application waits for the return value of the Jcl Method and I'm not able to reactivate it. Real problem is that the e-mail window is behind my application and I can't compose the message.
i've had no luck on the internet searching.
Have you ever experienced this problem?
You might want to switch to using the Outlook Object Model instead of Simple MAPI. This way you can bring Outlook's main window to the foreground first before displaying the message. Outlook's HWND can be retrieved by casting the Explorer object (returned buy Application.ActiveExplorer) to IOleWindow and calling IOleWindow.GetWindow. Once you have HWND, you can bring it to the foreground using something like the folloowing:
function ForceForegroundWindow(hWnd: THandle): BOOL;
var
hCurWnd: THandle;
begin
hCurWnd := GetForegroundWindow;
AttachThreadInput(
GetWindowThreadProcessId(hCurWnd, nil),
GetCurrentThreadId, True);
Result := SetForegroundWindow(hWnd);
AttachThreadInput(
GetWindowThreadProcessId(hCurWnd, nil),
GetCurrentThreadId, False);
end;
Related
In my Delphi 10.4 FMX program, I am asking the user for a new file name using the code below
procedure TForm6.btnBlockingClick(Sender: TObject);
begin
//In Win10, this blocks form access when ShowMessage is called
NameCallBack(mrOk, ['name']);
end;
procedure TForm6.btnNonBlockingClick(Sender: TObject);
begin
//In Win10, this does not block form access when ShowMessage is called in the NameCallBack routine.
TDialogService.InputQuery('Enter name', ['Name'], [''], NameCallBack);
end;
procedure TForm6.NameCallBack(const AResult: TModalResult; const AValues: array of string);
begin
if aResult = mrOK then
TDialogService.ShowMessage('Ok pressed')
else
TDialogService.ShowMessage('Cancel pressed');
end;
Any idea why ShowMessage is not blocking when NameCallBack is used as the Callback event for InputQuery? In Win10, what is the best way to show a message to a user in this type of callback routine that keeps the user from accessing the underlying form until the dialog is closed in some way.
FYI: the same thing happens if you use MessageDialog, to allow user interaction, instead of ShowMessage in the callback routine.
Note: this logic works in OSX and IOS, with both dialogs blocking. On Android, neither dialog is blocking but is not a problem, as touching anywhere but the dialogs closes the dialog and requires a second touch to interact with the underlying form again. On Win10, I can doing anything I want with the underlying form while the ShowMessage dialog is visible when used in a callback event.
Thanks for any help with this.
This may not be the best way to work around the bug I found, but here is what I did in case someone else has this problem.
I added a timer to my form, set the interval to 200 and disabled it.
For any TDialogServices.MessageDialog and TDialogServices.InputQuery callback routine where the callback routine also called MessageDialog or ShowMessage, I moved the callback logic into new routines. I then changed the callback routines to set a form variable to indicate which callback routine was called, saved off the relevant info from the callback routine as needed, then enabled the timer.
In the timer event, I first disable the timer then call the new routines based on the form variable.
This now allows both the original dialog and the dialog needed in the callback routine to be blocking on Win10. In addition, Android, OSX and IOS appear to still work correctly as explained in my question.
I'm starting to have issues with my main form disappearing behind other application windows on closing modal forms and I was hoping someone would have come across (and solved!) this issue previously or have suggestions on where to locate breakpoints to debug the problem.
My issues originally started with the classic 'shy dialog' problem with modal dialogs appearing under the main form which occurred intermittently. To try to sort this I changed all my modal forms' popupmode to pmAuto and also added
Application.ModalPopupMode := pmAuto;
and Application.MainFormOnTaskBar := true; to my application dpr.
Now I'm getting the main form disappearing behind other windows on closing the modal pop-ups. I have suspicion is that the behaviour is mainly caused when a modal form opens a second window (I've problems with both a MessageDlg and a straight Form.create(Application); Form.show;), though there's no obvious problems with the show/free code (ShowModal forms are created owner = nil, modeless with owner = application). In both cases the form disappears on closing the first original modal form, but manipulating the modal form without triggering a new form/dialog to appear seems to work as expected.
There are other nasties going on in the background on the main form with a refresh timer that activates a background thread, but usually this hasn't fired in the time it takes to see it not working. Other than that we are firing off calls to a remote server via a third-party DLL (the application is effectively a client-side GUI).
Annoyingly I can't get a mini program to mimic the behaviour and running in the IDE makes seeing the behaviour difficult, as the IDE itself contains a lot of windows that muddy the Z-ordering.
Edit - After writing my answer below, it appears I'm getting a deactivate event sent to the application (I can catch it through Application.OnDeactivate) - it seems similar to WPF App loses completely focus on window close Delphi doesn't have the Activate method that the c# solutions have, but I'll play with some windows messaging to see if I get anywhere
Following David's advice in comments I created a little logging form to be created on startup containing memo, timer and the following OnTimer event:
procedure TForm1.Timer1Timer(Sender: TObject);
function logtomemo(aHandle: HWND): TWinControl;
var
form: TWinControl;
begin
form := findControl(ahandle);
if form <> nil then
memo1.Lines.Add(format('handle %d - form %s', [ahandle, form.Name]));
result := form;
end;
var
handle: HWND;
form: TWinControl;
begin
memo1.Clear;
handle := application.ActiveFormHandle;
repeat
form := logtomemo(handle);
handle := GetWindow(handle, GW_OWNER);
until (handle = application.MainFormHandle) or (form = nil);
logtomemo(handle);
end;
Clicking around I noticed that as soon as I clicked outside of my application, our splash form appeared as the only form in the list. (Historically our splash screen used to only be freed after Application.Run, as they used to keep some other references on it for some reason - before my time and wasn't really needed anymore).
Changing the lifetime of the splashscreen to be destroyed before Application.Run appears to have sorted the issue - something that I'd never have guessed would be the cause in a million years.
Need a final sign-off that it doesn't reappear once I get rid of this little debug form, but hopefully a problem that's been frustrating me for a few days is now sorted - thanks!
Edit
As I noted in my edit and the comments to this question, the above debug didn't work, as the presence of the new form 'fixed' the problem. Changing the code so the output was sent to the Event Log or a text file rather than requiring a form also didn't reveal anything - all forms in the Z order remained in place.
In the end, I was able to fix the symptom rather than the cause by attaching the following code to Application.OnModalEnd
if Application.ModalLevel = 0 then
Windows.SetActiveWindow(Application.MainFormHandle);
This successfully sets the active window back to the main form after the last modal dialog has been closed.
This may have some side-effects if the user is expecting a non-modal form that isn't the main form to regain focus, but our application architecture doesn't really follow this structure and with Application.MainFormOnTaskbar, the main form won't hide the other forms (as long as they're not unparented)
In this interesting blog post on delphiXtreme I read about DUnit's built-in GUI testing capabilities (basically an alternative test case class TGUITestCase defined in unit GUITesting that has several utility functions for invoking actions in the GUI). I was quite happy with it until I noticed that it didn't work with modal forms. For example the following sequence won't work if the first button shows a modal configuration form:
Click ('OpenConfigButton');
Click ('OkButton');
The second Click is only executed when the modal form is closed, which I have to do manually.
I don't know much about how modal forms work in the background but there must be some way to circumvent this behaviour. Naively, I want to somehow execute the ShowModal "in a thread" so that the "main thread" stay responsive. Now I know that running ShowModal in a thread will probably mess up everything. Are there any alternatives? any way to circumvent the blocking nature of a ShowModal? Has anybody some experiences with GUI testing in Delphi?
I know about external tools (from QA or others) and we use those tools, but this question is about GUI testing within the IDE.
Thanks!
You can't test modal forms by calling ShowModal; because as you have quite rightly discovered, that results in your test case code 'pausing' while the modal form awaits user interaction.
The reason for this is that ShowModal switches you into a "secondary message loop" that does not exit until the form closes.
However, modal forms can still be tested.
Show the usually Modal form using the normal Show method.
This allows your test case code to continue, and simulate user actions.
These actions and effects can be tested as normal.
You will want an additional test quite particular to Modal forms:
A modal form is usually closed by setting the modal result.
The fact that you used Show means the form won't be closed by setting the modal result.
Which is fine, because if you now simulate clicking the "Ok" button...
You can simply check that the ModalResult is correct.
WARNING
You can use this technique to test a specific modal form by explicitly showing it non-modally. However, any code under test that shows a modal form (e.g. Error Dialog) will pause your test case.
Even your sample code: Click ('OpenConfigButton'); results in ShowModal being called, and cannot be tested in that manner.
To resolve this, you need your "show commands" to be injectible into your application. If you're unfamliar with dependency injection, I recommend Misko Hevery's Clean Code Talks videos available on You Tube. Then while testing, you inject a suitable version of your "show commands" that won't show a modal form.
For example, your modal form may show an error dialog if validation fails when the Ok button is clicked.
So:
1) Define an interface (or abstract base class) to display an error messages.
IErrorMessage = interface
procedure ShowError(AMsg: String);
end;
2) The form you're testing can hold an injected reference to the interface (FErrorMessage: IErrorMessage), and use it to show an error whenever validation fails.
procedure TForm1.OnOkClick;
begin
if (Edit1.Text = '') then
FErrorMessage.ShowError('Please fill in your name');
else
ModalResult := mrOk; //which would close the form if shown modally
end;
3) The default version of IErrorMessage used / injected for production code will simply display the message as usual.
4) Test code will inject a mock version of IErrorMessage to prevent your tests from being paused.
5) Your tests can now execute cases that would ordinarily display an error message.
procedure TTestClass.TestValidationOfBlankEdit;
begin
Form1.Show; //non-modally
//Do not set a value for Edit1.Text;
Click('OkButton');
CheckEquals(0, Form1.ModalResult); //Note the form should NOT close if validation fails
end;
6) You can take the mock IErrorMessage a step further to actually verify the message text.
TMockErrorMessage = class(TInterfaceObject, IErrorMessage)
private
FLastErrorMsg: String;
protected
procedure ShowError(AMsg: String); //Implementaion trivial
public
property LastErrorMsg: String read FLastErrorMsg;
end;
TTestClass = class(TGUITesting)
private
//NOTE!
//On the test class you keep a reference to the object type - NOT the interface type
//This is so you can access the LastErrorMsg property
FMockErrorMessage: TMockErrorMessage;
...
end;
procedure TTestClass.SetUp;
begin
FMockErrorMessage := TMockErrorMessage.Create;
//You need to ensure that reference counting doesn't result in the
//object being destroyed before you're done using it from the
//object reference you're holding.
//There are a few techniques: My preference is to explicitly _AddRef
//immediately after construction, and _Release when I would
//otherwise have destroyed the object.
end;
7) Now the earlier test becomes:
procedure TTestClass.TestValidationOfBlankEdit;
begin
Form1.Show; //non-modally
//Do not set a value for Edit1.Text;
Click('OkButton');
CheckEquals(0, Form1.ModalResult); //Note the form should NOT close if validation fails
CheckEqulsString('Please fill in your name', FMockErrorMessage.LastErrorMsg);
end;
There is actually a way to test modal windows in Delphi. When a modal window is shown your application still processes windows messages so you could post a message to some helper window just before showing the modal window. Then your message would be handled from the modal loop allowing you to execute code while the modal window is still visible.
Recently I've been working on a simple library to handle this very problem. You can download the code from here: https://github.com/tomazy/DelphiUtils (see: FutureWindows.pas).
Sample usage:
uses
Forms,
FutureWindows;
procedure TFutureWindowsTestCase.TestSample;
begin
TFutureWindows.Expect(TForm.ClassName)
.ExecProc(
procedure (const AWindow: IWindow)
var
myForm: TForm;
begin
myForm := AWindow.AsControl as TForm;
CheckEquals('', myForm.Caption);
myForm.Caption := 'test caption';
myForm.Close();
end
);
with TForm.Create(Application) do
try
Caption := '';
ShowModal();
CheckEquals('test caption', Caption);
finally
Free;
end;
end;
I implement this chevron tool bar in my application and it works perfectly great; however, when I clicked on any items on the menu, my application loses focus. Even if I move my mouse over the the corner of the form, the cursor doesn't change to the resize handle. I need to click on the form or application in order to regain focus which I would not like to have to do. Calling MainForm.Setfocus after calling the menu item doesn't help. I would like to have the focus be automatically on my application so my users don't need to click on the form before doing the things they need to do.
Any idea on how to regain focus on the form and/or application?
Thanks
Intercept the WM_KillFocus message.
pseudo code
don't have Delphi on this terminal, will fill in the blanks when home.
type
TForm1 = class(TForm)
...
protected
procedure WMKillFocus(message: TWM_Killfocus); message WM_KillFocus;
...
procedure TForm1.WMKillFocus(message: TWM_Killfocus);
begin
//do stuff to prevent the focus from shifting.
//do *NOT* call SetFocus, it confuses Windows/Delphi and leads to suffering
//Call PostMessage or handle the KillFocus message
//From MSDN
//While processing this message, do not make any function calls that display
//or activate a window. This causes the thread to yield control and can
//cause the application to stop responding to messages. For more information
//see Message Deadlocks.
//Also don't use SendMessage, PostMessage is OK though.
//Suggestion:
PostMessage(Self.handle, WM_SETFOCUS, 0, 0);
end;
How do I get the KeyDown event to work in a Delphi (2007) MDI Applications Parent window, even if a Child window has focus?
I would like to implement a shortcut key (F1) that brings up a help screen in a MDI application, I have added the KeyDown procedure to the MDI Parent window and enabled KeyPreview in both the Parent and Child windows, but it does not work as expected.
If I put a break point in the Parents KeyDown code I can see it never executes, even it there are no child windows open. But if I add the same code to the child window it works fine.
Is there a way to get the parent window to receive the key presses, even if the child window has focus, as adding the code to 25+ forms seams a little wasteful?
I had the exact same problem this week! I fixed it by creating an action in the ActionManager on the mainform. This action opens the help file and has the F1-key set as shortcut. It also works for all MDI child screens.
You could use a local (global is not needed) keyboard hook. You could also derive all your MDI Child forms from a signle form base class and implement it there once. You will find that this design comes in handy for other problems as well.
edit
Application wide hotkeys/shortcuts can also be implemented with the TApplication.OnShortCut event. See http://delphi.about.com/od/adptips2004/a/bltip0904_3.htm
F1 is already the standard help shortcut which triggers TApplication.OnHelp. So maybe you want to use the OnHelp event? And if you use the HelpFile, HelpContext, HelpType and HelpKeyword properties you probably don't even need to implement any code at all.
How do I get the KeyDown event to work in a Delphi (2007) MDI Applications Parent window, even if a Child window has focus?
As a more generic solution (for applications other than F1 for help) I use code similar to this to trap a keydown event in the main form. This gets all keys no matter what, even when an MDI child is active. In this example I'm doing the opposite of what you are trying to do (I want the message to be handled by my child form instead of the main form), but the concept of catching the keys in the parent is the same).
Application.OnMessage := AppMessage;
procedure TMainForm.Appmessage(var Msg: TMsg; var Handled: Boolean);
var
message: TWMKey;
begin
If (msg.message = WM_KEYDOWN) and
( LoWord(msg.wparam) = VK_TAB ) and
(GetKeyState( VK_CONTROL ) < 0 ) and
Assigned( ActiveMDIChild ) then
Begin
Move( msg.message, message.msg, 3*sizeof(Cardinal));
message.result := 0;
Handled := ActiveMDIChild.IsShortcut( message );
End;
end;
F1 help processing is built into Delphi, so all you have to do is handle the help messages properly. This may be as little as setting the helpfile property for the application. You can set particular pages using the form's help??? properties.
Basically, just use the help system supplied and forget keydown. This is Delphi - you don't have to work hard.