.msg preview in 64Bit application not working - outlook

We are having problems with our 64Bit Application (Addin for Outlook). There is a feature that should display a preview of *.msg files in our application. It works fine with windows explorer and in Outlook 32Bit. When I try to open the file with our 64Bit application an error occurs:
"Either there is no default mail client or the current mail client cannot fulfill the messaging request. Please run Microsoft Outlook and set it as the default mail client."
I tried everything the internet suggests...
- Repair Outlook
- Outlook as default mail client
- New Outlook profile
- ...
It is NO option to install a 32Bit version of our software or to just "disable" this feature...
Does anyone have a solution that fixes this error?
Thanks in advance...

This is to be expected - a 64 bit app cannot load 32 bit dlls (that is what the MAPI system is).

If anyone in the future has the same problem:
We fixed this issue. Therefore we use this bits of code:
[..]
// read this documentation for explanation...
// https://learn.microsoft.com/en-us/windows/win32/api/wtypesbase/ne-wtypesbase-clsctx
const uint CLSCTX_LOCAL_SERVER = 4;
uint hResult = CoCreateInstance(ref guid, null,
CLSCTX_LOCAL_SERVER, ref IID_IUnknown, out instance);
mCurrentPreviewHandler = instance;
[..]
[DllImport("ole32.Dll")]
static public extern uint CoCreateInstance(ref Guid guid,
[MarshalAs(UnmanagedType.IUnknown)] object inner,
uint context,
ref Guid uuid,
[MarshalAs(UnmanagedType.IUnknown)] out object rReturnedComObject);
[..]

Related

Send email with RAD Studio cpp11

I am trying to port an old Borland C++ application to the new RAD studio 11 format an I cannot get it to send emails using Outlook_2K_SRVR.h.
Would anyone have sample code to send emails with RAD studio 11? in C++?
This is the part of the code that does not work.
`
`#define Outlook_2k_olMailItem OlItemType::olMailItem`
`//---------------------------------------------------------------------------
#pragma package(smart_init)
//----------------------------------
// emailing ...
//----------------------------------
#pragma link "Outlook_2K_SRVR"
void __fastcall TLicMainForm::Button1Click(TObject *Sender)
{
MailItem = (MailItemPtr)(Outlook->CreateItem(Outlook_2k_olMailItem));
MailItem->set_To((MailAddressee.w_str() ));
MailItem->set_Subject((MailSubject.w_str()));
MailItem->set_Body((MailFullText.w_str()) );
MailItem->Attachments->Add( (TVariant)(FDispatch_path), TNoParam(), TNoParam(), TNoParam() );
MailItem->Send();
}`
`
this is the one of the many errors
[ilink32 Error] Error: Unresolved external '__fastcall Outlook_2k::TSyncObject::Disconnect()' referenced from C:\mypath\OUTLOOK_2K_SRVR.OBJ
[ilink32 Error] Error: Unable to perform link
Thanks in advance
I tried to re-compile "Outlook_2k_SRVR.obj" with the .h file that comes in the vcl folder but no luck.
It seems Outlook is disconnected right after the Send method is called. Most probably the new RAD studio release COM references quickly enough. You may try to get any Outlook window and keep it alive while Outlook is automated and the message is sent out. Try to use the Explorers.Add or Inspectors.Add methods to create an Outlook window, be aware that without calling the Display method the window will be kept not visible to the end user.

Launch Visual Studio 2012 Shell (Integrated) and run SSIS package using Windows Scheduler

I am working on a project that creates a reporting database by loading data from an AS400 into SQL Server 2012 Express (just FYI - I do not have sql agent or sql profiler). I downloaded sql server data tools with the SSIS designer and created a couple of data loading packages within the same solution. I have researched running SSIS packages using the DTExec utility, and for the most part it worked fine, however, I was not able to log any of the runtime data to a log table (only the text file log worked), and for some reason the send emails tasks didn't send emails when run through DTExec. Both of these things worked fine when running the packages directly in VS Shell.
While trying to troubleshoot these issues, I realized that I do not actually have integration services installed on my machine - just the designer. I will not be able to get integration services (soon, at least) so I would like to figure out how to launch VS Shell, validate, build and execute my SSIS load packages - not using the DTExec utility, but actually launching in the VS Shell using Windows Scheduler.
I know that to launch the program itself, I would just schedule devenv.exe. But what arguments do I use to validate, build and execute the packages using this method. The only thing I can find about executing packages involves using the utility, and assumes that the user has SSIS installed, not just the designer.
Now, if worse comes to worse I can just execute the load packages and then create some sql queries to pull together the row counts and other stuff I will need to audit the data, but it seems like there should be a way to do what I want to do.
There's a reason you're not able to run an SSIS package outside of BIDS/SSDT/Visual Studio and it's called licensing.
With the 2012 release of SQL Server, you're free to develop SSIS packages to your heart's content. However, to get them to run outside of Visual Studio means you need to have installed SQL Server on the invoking machine. Even though it's "just integration services", that's a SQL Server installation and thus a license is required. A developer edition license of SQL Server is cheap: ~50 USD per user. However, since it sounds like you're making a "productionalized" version, you're going to need a Standard Edition or Enterprise Edition, depending on the features used in SSIS. SE or EE is not cheap and with the change to licensing with the 2012 release (per core vs per socket), it's gotten more precious.
You're looking for a technical solution and if you find one, you're likely going to be in violation of licensing.
You can use AutoIT to script GUI applications:
http://www.autoitscript.com/site/autoit/
I managed to figure out how to launch VS using the windows scheduler:
create a task
go to actions, edit
In the program/script box enter the path to devenv.exe (using double quotes) - "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe"
In Add arguments enter devenv /runexit /project [project name] "\fileserver\path[solution name].sln"
You can use other switches for arguments: http://msdn.microsoft.com/en-us/library/xee0c8y7.aspx
The only thing is that because it is running in visual studio (at least for me) is that it runs in debug mode, so you have to click stop to stop debugging. So in my case, I used the runexit switch, which is supposed to close VS when the package is complete. It only closed after I clicked stop. I tried using the /command switch to execute a stop debugging command (http://msdn.microsoft.com/en-us/library/c3a0kd3x.aspx) Debug.StopDebugging, but it didn't seem to work.
I used the run flag in task scheduler and I was able to get the the debugger to automatically stop by taking advantage of user32.dll via a script. Basically I send the close command message and a button click to the ok on the close dialog. Below is my cookie cutter task I put at the end of my projects... If you just want to stop without exit you could probably just send shift+f5 too.
private static string project = "MyProjectName";
[DllImportAttribute("User32.dll")]
private static extern int FindWindow(String ClassName, String WindowName);
[DllImport("user32.dll", CharSet = CharSet.Auto)]
static extern IntPtr SendMessage(int hWnd, UInt32 Msg, IntPtr wParam, IntPtr lParam);
[DllImport("user32.dll", SetLastError = true)]
public static extern int FindWindowEx(int parentHandle, IntPtr childAfter, string className, string windowTitle);
const UInt32 WM_CLOSE = 0x0010;
private const int BN_CLICKED = 245;
/// <summary>
/// This method is called when this script task executes in the control flow.
/// Before returning from this method, set the value of Dts.TaskResult to indicate success or failure.
/// To open Help, press F1.
/// </summary>
public void Main()
{
int hwndChild = 0;
int hWnd = FindWindow(null, project + " (Running) - Microsoft Visual Studio (Administrator)");
if (hWnd == 0)
hWnd = FindWindow(null, project + " (Running) - Microsoft Visual Studio");
if (hWnd == 0)
hWnd = FindWindow(null, project + " - Microsoft Visual Studio");
if (hWnd > 0)
{
SendMessage(hWnd, WM_CLOSE, IntPtr.Zero, IntPtr.Zero);
while (hwndChild == 0)
{
hWnd = FindWindow(null, "Microsoft Visual Studio");
hwndChild = FindWindowEx(hWnd, IntPtr.Zero, "Button", "&Yes");
if (hwndChild == 0)
hwndChild = FindWindowEx(hWnd, IntPtr.Zero, "Button", "Yes");
SendMessage(hwndChild, BN_CLICKED, IntPtr.Zero, IntPtr.Zero);
System.Threading.Thread.Sleep(500);
System.Windows.Forms.Application.DoEvents();
}
}
Dts.TaskResult = (int)ScriptResults.Success;
}

CFileDialog::OnInitDialog() does not call

I am using custom file dialog which is extended from the CFileDialog.
The problem is that, OninitDialog() does not get called before DoModal().
I have customized the CFileDialog in the OninitDialog().
I am using VS 2012 with Win7 OS.
I could not find out, what is going wrong.
I just run into same issue today; I think I found a valid solution, in constructor of your class just set m_bVistaStyle = FALSE;
After doing this, I got OnInitDialog and I was able to customize this dialog just fine.
CMyOpenDlg::CMyOpenDlg(LPCTSTR lpszDefExt, LPCTSTR lpszFileName,
DWORD dwFlags, LPCTSTR lpszFilter, CWnd* pParentWnd) :
CFileDialog(TRUE, lpszDefExt, lpszFileName, dwFlags, lpszFilter, pParentWnd)
{
m_bVistaStyle = FALSE;
The Microsoft documentation says that OnInitDialog is not supported on Windows Vista.
The same is true for Windows 7 (and probably also for Windows 8).

System file copying dialog box

Sometimes, setup programs shows the Windows file copy dialog, like this one:
This often appears during driver-level application installation, either on Windows XP or Windows 7.
Which API can perform that?
EDIT
Actually, there is no Cancel button at all on the real dialog box.
The Windows API is called SHFileOperation.
Its signature in C# language is
[DllImport("shell32.dll",CharSet = CharSet.Unicode)]
static extern int SHFileOperation([In] ref SHFILEOPSTRUCT lpFileOp);
If you like an example you could look at this page on PInvoke
This instead is the link to the MSDN documentation on SHFileOperation
The Windows API SHFileOperation is declared as follows:
[DllImport("shell32.dll",CharSet = CharSet.Unicode)]
static extern int SHFileOperation(ref SHFILEOPSTRUCT lpFileOp);
Specifying [In] for ref SHFILEOPSTRUCT lpFileOp prevents receiving the pointer to any remapped files in ref SHFILEOPSTRUCT.hNameMappings when FOF_WANTMAPPINGHANDLE flag is set.

How do I disable the 'Debug / Close Application' dialog on Windows Vista?

When an application crashes on Windows and a debugger such as Visual Studio is installed the following modal dialog appears:
[Title: Microsoft Windows]
X has stopped working
A problem caused the program to stop
working correctly. Windows will close
the program and notify you if a
solution is available.
[Debug][Close Application]
Is there a way to disable this dialog? That is, have the program just crash and burn silently?
My scenario is that I would like to run several automated tests, some of which will crash due to bugs in the application under test. I don't want these dialogs stalling the automation run.
Searching around I think I've located the solution for disabling this on Windows XP, which is nuking this reg key:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
However, that did not work on Windows Vista.
To force Windows Error Reporting (WER) to take a crash dump and close the app, instead of prompting you to debug the program, you can set these registry entries:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting]
"ForceQueue"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\Consent]
"DefaultConsent"=dword:00000001
After this is set, when your apps crash, you should see *.hdmp and *.mdmp files in:
%ALLUSERSPROFILE%\Microsoft\Windows\WER\
See here:
http://msdn.microsoft.com/en-us/library/bb513638.aspx
regedit
DWORD HKLM or HKCU\Software\Microsoft\Windows\Windows Error Reporting\DontShowUI = "1"
will make WER silently report. Then you can set
DWORD HKLM or HKCU\Software\Microsoft\Windows\Windows Error Reporting\Disabled = "1"
to stop it from talking to MS.
I'm not sure if this refers to exactly the same dialog but here is an alternative approach from Raymond Chen:
DWORD dwMode = SetErrorMode(SEM_NOGPFAULTERRORBOX);
SetErrorMode(dwMode | SEM_NOGPFAULTERRORBOX);
I had to disable this for release automation work on Windows 64-bits for Firefox and I did the following:
gpedit.msc
Computer configuration -> Administrative Templates
Windows Components -> Windows Error Reporting
Set "Prevent display of the user interface for critical errors" to Enabled
It is similar what was accomplished for Customer Experience reporting in:
http://www.blogsdna.com/2137/fix-windows-installer-explorer-update-has-stopped-working-in-windows-7.htm
In my context, I only want to suppress the popup for my unit tests and not for the entire system. I've found that a combination of functions are needed in order to suppress these errors, such as catching unhandled exceptions, suppressing run time checks (such as the validity of the stack pointer) and the error mode flags. This is what I've used with some success:
#include <windows.h>
#include <rtcapi.h>
int exception_handler(LPEXCEPTION_POINTERS p)
{
printf("Exception detected during the unit tests!\n");
exit(1);
}
int runtime_check_handler(int errorType, const char *filename, int linenumber, const char *moduleName, const char *format, ...)
{
printf("Error type %d at %s line %d in %s", errorType, filename, linenumber, moduleName);
exit(1);
}
int main()
{
DWORD dwMode = SetErrorMode(SEM_NOGPFAULTERRORBOX);
SetErrorMode(dwMode | SEM_NOGPFAULTERRORBOX);
SetUnhandledExceptionFilter((LPTOP_LEVEL_EXCEPTION_FILTER)&exception_handler);
_RTC_SetErrorFunc(&runtime_check_handler);
// Run your tests here
return 0;
}
In WPF application
[DllImport("kernel32.dll", SetLastError = true)]
static extern int SetErrorMode(int wMode);
[DllImport("kernel32.dll")]
static extern FilterDelegate SetUnhandledExceptionFilter(FilterDelegate lpTopLevelExceptionFilter);
public delegate bool FilterDelegate(Exception ex);
public static void DisableChashReport()
{
FilterDelegate fd = delegate(Exception ex)
{
return true;
};
SetUnhandledExceptionFilter(fd);
SetErrorMode(SetErrorMode(0) | 0x0002 );
}
You have to implement an unhandled exception filter which simply quits your application, then set that filter function with SetUnhandledExceptionFilter().
If you're using the secure CRT, you also have to provide your own invalid parameter handler and set this with _set_invalid_parameter_handler().
This blog post has some information too:
http://blog.kalmbachnet.de/?postid=75
During test you can run with a 'debugger' like ADPlus attached which can be configured in many useful ways to collect data (minidumps) on errors and yet prevent the modal dialog problems you state above.
If you want to get some useful information when your app crashes in production you can configure Microsoft Error reporting to get something similar to ADPlus data.
This isn't a direct answer to the question since this is a workaround and the question is about how to disable that feature, but in my case, I'm a user on a server with limited permissions and cannot disable the feature using one of the other answers. So, I needed a workaround. This will likely work for at least some others who end up on this question.
I used autohotkey portable and created a macro that once a minute checks to see if the popup box exists, and if it does, clicks the button to close the program. In my case, that's sufficient, and leaves the feature on for other users. It requires that I start the script when I run the at-risk program, but it works for my needs.
The script is as follows:
sleep_duration = 60000 ; how often to check, in milliseconds.
; 60000 is a full minute
Loop
{
IfWinExist, ahk_class #32770 ; use autohotkey's window spy to confirm that
; ahk_class #32770 is it for you. This seemed to be consistent
; across all errors like this on Windows Server 2008
{
ControlClick, Button2, ahk_class #32770 ; sends the click.
; Button2 is the control name and then the following
; is that window name again
}
Sleep, sleep_duration ; wait for the time set above
}
edit: A quick flag. When other things are up, this seems to attempt to activate controls in the foreground window - it's supposed to send it to the program in the background. If I find a fix, I'll edit this answer to reflect it, but for now, be cautious about using this and trying to do other work on a machine at the same time.
After trying everything else on the internet to get rid of just in time debugger, I found a simple way that actually worked and I hope will help someone else.
Go to Control Panel
Go to Administrative Tools
Go to Services
Look down the list for Machine Debug Manager
Right Click on it and click on Properties
Under the General Tab, look for Start Up Type
Click on Disable.
Click on Apply and OK.
I haven't seen the debugger message since, and my computer is running perfectly.
Instead of changing values in the registry you can completly disable the error reporting on Windows Server 2008 R2, Windows Server 2012 and Windows 8 with: serverWerOptin /disable
https://technet.microsoft.com/en-us/library/hh875648(v=ws.11).aspx

Resources