COM/DCOM Exception Class

This article includes an updated SYSEX exception class. I would like to thank Dale Nagata for testing out the earlier version with an in-process server (something I had not done) and for pointing some nasty problems. The updated version includes fixes to these as well as some other enhancements.

The updated version now propagates error line number and file occurences in the source window as demonstrated above. It also includes some additional macros which you may or may not find useful. One of the issues pointed out by Dale was the inability of the previous version to display the correct module name in the source window when using an in-process server. The fix I decided on was to include an external global variable initialized as follows HINSTANCE g_hMODInstance=NULL which you can set in DLLMain.

#include "sysex.h"

BOOL WINAPI DllMain(HINSTANCE hInstance, 
                    DWORD dwReason, 
                    LPVOID /* lpReserved */)
{
 if (dwReason == DLL_PROCESS_ATTACH)
 {
  g_hMODInstance=hInstance;
  _Module.Init(ObjectMap, hInstance, &LIBID_SYSEXSERVERLib);
  DisableThreadLibraryCalls(hInstance);
 }
 else if (dwReason == DLL_PROCESS_DETACH)
 {
  g_hMODInstance=NULL;
  _Module.Term();
 }
 return TRUE;    // ok
}

I apologize for the delay in getting the fixes done. Please feel free to modify the code if you see fit.

Reg.

Downloads

Download demo project - 27 Kb
Download source - 5 Kb


Comments

  • There are no comments yet. Be the first to comment!

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Wednesday, September 24, 2014 8:00 AM - 9:00 AM PDT According to a recent Forrester Research report, many companies are choosing low-code platforms over traditional programming platforms, due to the speed with which low-code apps can be assembled and tested. With customer-facing applications on the rise, traditional programming platforms simply can't keep up with the "short schedules and rapid change cycles" required to develop these applications. Check out this upcoming webinar and join Clay Richardson from …

  • Packaged application development teams frequently operate with limited testing environments due to time and labor constraints. By virtualizing the entire application stack, packaged application development teams can deliver business results faster, at higher quality, and with lower risk.

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds