I just recently added a TAdvDocPanel, TAdvToolBar and TAdvGlowButton to my application's main window. Now when using the Jedi compenent's JvMail.SendMail with an Outlook client, the email composition window of Outlook shows up behind my application and you cannot bring it forward... my app remains on top.
I checked the AdvToolBar/AdvDockPanel code but could not see a reason for this. This doesn't affect how the form becomes active or the z-index of the form.
Our main form which descends from TForm and contains your toolbar in a panel, opens a modal print dialog, which in turn opens a modal PDF save dialog if the user chose to print to a PDF. Once the PDF is created, another modal dialog opens up to view or email the document. If the user chooses to view it, it opens the associated PDF reader which is usually Acrobat Reader. This comes forward fine. If the user choose to email, it opens the default email client via JvMail.Send. If it is Outlook, the main window of our app suddenly comes to the foreground (even above our PDF completed dialog and our Print Report dialog, all modal) and the Outlook composition dialog stays in the background. This is also true for Windows Live Mail, so it is not specific to Outlook. This occurs on Win7 and Win 8.1. The app is compiled with Delphi 2007. If our app is full screen, the user is screwed since they are locked out until the composition window is closed since it is opened modal. When you close the composition window, the next modal windows then comes to the foreground... close that and the next once comes into view until we are back at the main window.
We do not have a component JvMail here.
Can this be reproduced in another way?
JvMail is part of the Jedi Code Library (JCL/JVCL). I also just tried it with MAPIMail from the free SMComponents from scalabium.com with the same results. I'll keep playing with it to see if I can duplicate it without using third party components.
FYI, if I use ShellExecute to launch the default email client it works fine, but I believe I can't include an attachment. Note: I got the following example off of a Google search and didn't change it much:
Here is a function that uses the Mapi unit without a 3rd party component. If you cannot duplicate, I will put a sample program together.
// The following based on an example provided at:
// http://www.delphifaq.com/faq/delphi/network/f236.shtml
function SendMailMAPI(
const pSubject, pBody, pFileName, pSenderName, pSenderEMail,
pRecepientName, pRecipientEmail: String) : Integer;
var
vMapiMessage: TMapiMessage;
vSenderDesc, vRecipientDesc: TMapiRecipDesc;
vFileAttach: TMapiFileDesc;
vMapiSendMail: TFNMapiSendMail;
vMAPIModule: HModule;
begin
FillChar(vMapiMessage, SizeOf(vMapiMessage), 0);
with vMapiMessage do
begin
if (pSubject<>'') then
begin
lpszSubject := PChar(pSubject)
end;
if (pBody<>'') then
begin
lpszNoteText := PChar(pBody)
end;
if (pSenderEMail<>'') then
begin
vSenderDesc.ulRecipClass := MAPI_ORIG;
if (pSenderName='') then
begin
vSenderDesc.lpszName := PChar(pSenderEMail)
end else
begin
vSenderDesc.lpszName := PChar(pSenderName)
end;
vSenderDesc.lpszAddress := PChar('SMTP:'+pSenderEMail);
vSenderDesc.ulReserved := 0;
vSenderDesc.ulEIDSize := 0;
vSenderDesc.lpEntryID := nil;
lpOriginator := @vSenderDesc;
end;
if (pRecipientEmail<>'') then
begin
vRecipientDesc.ulRecipClass := MAPI_TO;
if (pRecepientName='') then
begin
vRecipientDesc.lpszName := PChar(pRecipientEmail)
end else
begin
vRecipientDesc.lpszName := PChar(pRecepientName)
end;
vRecipientDesc.lpszAddress := PChar('SMTP:'+pRecipientEmail);
vRecipientDesc.ulReserved := 0;
vRecipientDesc.ulEIDSize := 0;
vRecipientDesc.lpEntryID := nil;
nRecipCount := 1;
lpRecips := @vRecipientDesc;
end else
begin
lpRecips := nil
end;
if (pFileName='') then
begin
nFileCount := 0;
lpFiles := nil;
end else
begin
FillChar(vFileAttach, SizeOf(vFileAttach), 0);
vFileAttach.nPosition := Cardinal($FFFFFFFF);
vFileAttach.lpszPathName := PChar(pFileName);
nFileCount := 1;
lpFiles := @vFileAttach;
end;
end;
vMAPIModule := LoadLibrary(PChar(MAPIDLL));
if vMAPIModule=0 then
begin
Result := -1
end else
begin
try
@vMapiSendMail := GetProcAddress(vMAPIModule, 'MAPISendMail');
if @vMapiSendMail<>nil then
begin
Result := vMapiSendMail(
0, Application.Handle, vMapiMessage, MAPI_DIALOG or MAPI_LOGON_UI, 0
);
end else
begin
Result := 1
end;
finally
FreeLibrary(vMAPIModule);
end;
end;
end;
In trying to put together a test program for you, I am not able to duplicate the issue in a test program readily. Hold off doing anything on this until you hear back from me.
OK Guys.. found the problem. It falls back on my Splash screen which is brought forward using BringToFront. Only the splash screen is brought to the front and closes and frees itself once the main form has finished loading. However, when using your toolbar stuff, it seems that the main program has now taken on that setting somehow. This was not occurring prior to using your toolbar stuff.
Is this our TAdvSmoothSplashScreen?
No, home grown from about 8 years ago. I wouldn't spend too much time on it. After talking with my support guy about what I found, he says we've had a few customer issues where other dialogs of our own have shown up behind our main app (rare, but does occur, and is recoverable by switching tasks and back again). Not exactly the same thing but I'm wondering if D2007's handling of BringToFront is flawed in some regards or I have a misunderstanding of its usage, and that your toolbar components simply exposed it in a reproducible way. We used to use StayOnTop for our splash screen, however if our main app had an error during load, the error msg would show up behind the splash screen, so we moved to BringToFront. Now that we have your tools, I might look at your TAdvSmoothSplashScreen.
Sigh... I'm getting reports from customers that my "fix" has not completely eliminated the issue. I'll try to create a reproducible example and get it to you.