One of the most frustrating limitations of the C API is the synchronous nature it imposes. Many programmers want to exert control over Excel at arbitrary times. Perhaps the goal is to start a process in Microsoft Excel each time a stock price comes in on the Internet. The C API doesn't enable this scenario. It is necessary for Microsoft Excel to call the developer's code before the developer is allowed to utilize the C API to call functionality within Microsoft Excel. An example of the proper way to use the C API is when a function in your DLL is called as part of recalculation, your DLL utilizes the C API to get additional information and returns. An improper utilization would be to call your DLL as part of recalculation and then have your DLL set a timer and return. When the timer fires, the DLL will attempt to call back into Microsoft Excel. This will not work. The OLE Automation interface doesn't experience this limitation. Whenever Microsoft Excel is in a ready state, OLE Automation calls may be performed on it's methods and properties. There are a few times when Microsoft Excel appears to be in a ready state and will not respond to OLE Automation (for example, when dialogs are showing, menus are pulled down, or macro code is executing). These exceptions are much less limiting than the limits imposed by the C API. If you truly need asynchronous access to Excel you should choose the OLE Automation Interface.