Derive your interfaces from IDispatch if you want to be automation compatible. In Excel case the interface probably has a method called "Worksheets" which takes a BSTR param and returns a Range object : IExcelInterface::Worksheets(BSTR sheet) : Range; The object Range implements an interface IRange, which has a range method : IRange::Range(BSTR range) : Value; The value object has a property named "value". ... and so on. All you need to do is to expose your application object model ( COM object hierarchy ) to the automation clients ( scripts, binaries, etc ).

Alvaro Mendez wrote: I guess I'll just have to go on one of those miracle diets good one :laugh:

Eat ? Watch out, the gates of heaven are a little bit tight ;)

Paul Watson wrote: And Mulder proved you don't need equipment to find aliens, they come to you. All you need is a death wish and a father who smokes lots of cigarettes... :laugh: Hmmm... Maybe so,but somebody still have to pay you ( aka US government )

Who said anything about death ? :-D. To search for aliens you need a lot of equipment & stuff, to search for inner peace you need just some spare time :)

Probably cannot be proved, but there is the certainty that you will find the answer to the existence of god. About the aliens you will never know for sure :)

"First chance exception in ... : Microsoft C++ Exception" means a C++ exception is thrown but not catch. Try to wrap up your method call in a try / catch statement, and catch a _com_error exception. Take a look at the error code.

Maybe you can make the client to return to the server a picture object ( see IPicture OLE implementation in MSDN).

What's the exception code ?

Returning S_FALSE from DllCanUnloadNow should leave the dll loaded. I don't know VB, so I cannot tell exactly what that property does, but I suppose it will do the same thing ( return false from can unload now). Did you check if it's the same process ? ( maybe the process will exit, so normally all the dlls will be unloaded).

See the answer to "DCOM & Dual Lan" below [^]

The proper way to do it is to make your server a service, if your objects need to have some context setup once per session. The answer to your question is to return allways S_FALSE from DllCanUnloadNow. In case you are using ATL you can achieve this by having a CAtlModule::Lock call without CAtlModule::Unlock pair.

The apartment is initialized for each thread once when you call CoInitInstance ( Ex). If you use COINIT_MULTITHREADED, you can pass around the interface ptr without any problems in any thread marked as MTA. Between threads with different apartments you must marshall the interface ( you can use CoMarshalInterThreadInterfaceInStream / CoGetInterfaceAndReleaseStream)

You get to decide to which machine the client will connect, by specifying the remote server name in COSERVERINFO structure when calling CoCreateInstanceEx ( or by setting the appropriate value for RemoveServerName into the registry for the server component). DCOM does not have such failsafe mechanisms - if you cannot use the primary server anymore try to switch to the other one.

You cannot inherit from two interfaces derived from IDispatch, because the IDispatch is not a virtual base class ( as the error message is saying, the compiler cannot decide which base class to consider for casting).You can disambiguate the cast by specifying which base class to consider ( (IDispatch*)(IInterface1*)this). Another issue is that you will have DISPID clashes from the two interfaces ( id 1 assigned to method "test" in iface 1, and for method "clone" for iface2). The solution is dispid encoding ( you can find an article on codeguru about this), manually implementing IDispatch or using tear-off objects.

Something more contemporary : On War [^]

I perfectly agree - it is not supposed to work at all. I don’t understand why is working. Anyway, if you will take a look at the example in MSDN you'll see that the output is perfect ( compiled debug, I suppose ), even if the note says "MEMCPY.C: Illustrate overlapping copy: memmove, handles it correctly; memcpy does not" ;P

This protection seems to be implemented only in debug version, and I personally think is a major pain because it lets some easy to catch bugs to creep unobserved. I would expect release and debug versions to be consistent, not to have a different functionality :(

According to the documentation, memcpy does not guarantee the result if the source and destination overlap; on the other hand, memmove will graciously handle the case, by coping first the overlapping region. Consider the following example : char szTempCpy[] = "this is the most reliable test"; char szTempMov[] = "this is the most reliable test"; memcpy( szTempCpy + 5, szTempCpy, 25); memmove( szTempMov + 5, szTempMov, 25); printf("memcpy : %s\nmemmove : %s\n", szTempCpy, szTempMov); Now, when this is compiled in release you will get the correct behavior : memcpy will trash the data ( the ouput is "this this this this ...") and memmove will get it right ( "this this is the most ..."). The surprise comes when you compile debug : both memcpy and memmove will yield the same result ( the correct one ) - "this this is the most ...". Does anybody have a good explanation for this ?

here is something to keep you warm in the cold nights : http://museum.sysun.com/museum/[^] you can actually get to play with Altair BASIC ;) ( check exhibit hall)