I don't do a lot of non-MFC these days because I find the classes so useful. It's also hard to show something useful without it containing a lot of stuff that's specific to my application and would make no sense to you. CDBException is for errors coming from CDatabase and CRecordset classes.
Here's my general exception catcher in the main loop of my application. Ignore things that are related to sending messages back to the user (client / server app).
catch (CException * cfe)
if (!cfe->GetErrorMessage(exceptBuf, sizeof(exceptBuf)))
exceptBuf = '\0'; /* null out the message if no text associated with exception */
#endifif (claim_check != NULL)
ccnum = claim_check->getClaimCheck();
ccnum = "000000";
ts.Format("Internal Exception Trap - %s", exceptBuf);
TheLogFile->LogThis(ccnum + CString(" : ") + ts);
sendErrorToGUI(ts, E_DEFAULTERROR, TheCommCenter, claim_check, parsed_request, inputConfig);
} /* catch block */
Unfortunately CoCreateInstance isn't a C++ function so it won't throw exceptions - unless someone's implemented a wrapper or something around the function that we can't see in your example.
For COM and OLE functions you have to pull apart the HRESULT return value, preferably using the Microsoft macros and/or call GetLastError/FormatMessage. It's a pain in the bum but COM and OLE are pretty old now and MS haven't quite managed to kill it off or hide it yet.
What the various return values mean can be found here[^].
I didn't know it was old school, and thought it was the current way to talk to IIS 7+ web server.
It must of stopped due to one of the previous errors I made earlier. So I will use the hr check instead.
Thanks for the heads up on that.
// test and see if we can write to the AppHostWritableAdminManager
hr = CoCreateInstance( __uuidof( AppHostWritableAdminManager ), NULL,
CLSCTX_INPROC_SERVER, __uuidof( IAppHostWritableAdminManager ), (void**) &pMgr);
if ( FAILED( hr ) )
hello guys... This error has something to do with linking. I have a static library (which contains some virtual functions) and I have taken following steps to add it to my project.
- Project Name -> Add -> Existing Item . Chose and included header file.
- Project Name -> Properties -> C/C++ -> General -> Additional Include Directories. Navigated to the folder containing the header file.
- Project Name -> Properties -> Linker -> Input -> Additional Dependencies . Gave the path including the library_name.lib
Until here, it compiles successfully. But when I derive a class from a class in this header file, it starts giving this error like: Error LNK 2001 - Unresolved External Symbols? Whats wrong with this approach? Thanks for any input.
This world is going to explode due to international politics, SOON.
I'm not sure, but the specification of Additional Dependencies may only affect the bulding and re-building of your project. I think you have to specify additional linker directories to use and also additional libraries to include. This are usually in the same place or tab as the Additional Dependencies.
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
This looks like it should work... in the header that you have included, make sure you don't have to #define anything to specify that you are using the library instead of building it. Sometimes developers use the same exact header file to build the library than what others would use to import the library and just use pre-processor directives to tell the difference.
What are the external symbols that it can't find? Are they defined in the header?