1

Suppose I have a third-party DLL which exposes functionality via a class Foo. Foo expects me to provide callbacks by means of defining a class implementing the interface IBar.

I need to call into this third-party DLL from a DLL I have created, which is in turn called from a core executable. So my DLL contains code like this:

class MyBar : public IBar
{
public:
  // Implement the Frobble method of IBar
  virtual void Frobble() override
  {
    // ...callback code here...
  }
};

// Entry point from core executable
extern "C" __declspec(dllexport) void DoStuff()
{
  AFX_MANAGE_STATE(AfxGetStaticModuleState());
  MyBar myBar;
  Foo thirdPartyFoo;

  thirdPartyFoo(myBar);
}

Do I need to call AFX_MANAGE_STATE again inside MyBar::Frobble?

Chowlett
  • 45,935
  • 20
  • 116
  • 150
  • 1
    IMHO - Yes. In any case, it won't hurt. [See this question](http://stackoverflow.com/q/9062034/2065121) for more info. – Roger Rowland Jan 22 '15 at 15:22
  • I tend to use it only at the module boundaries (exported dll functions) so that I do not contaminate my classes. – user1793036 Jan 23 '15 at 01:21
  • 1
    Yes, this is required. Assuming that `thirdPartyFoo` is properly implemented, it, too, will switch to its module state. When it calls your `Frobble` callback, your initial module state has changed back to the third-party module's module state. The general rule is, that whenever you cross module boundaries you have to set the correct module state. – IInspectable Jan 25 '15 at 19:53

0 Answers0