title: Using a Qt-based DLL in a non-Qt application
body: <p>Am I doing it right?</p>
  
  <p>A client of mine has a group where I'm developing Qt-based client-server stuff with a lot of fun widget stuff and sockets.</p>
  
  <p>Another group within the company wants to use a wrapped version of the QTcpSocket-based client data provider classes.  (Which does basically what it sounds like, provides data from the server to the client displays)</p>
  
  <p>However, that group has a huge application built mostly with MFC, and that is simply not going to change any time soon.  The Qt-based DLL is also delay-loading so that it can be deployed without this feature in certain configurations.  </p>
  
  <p>I've got it working, but it's a little hacky.  Here's my solution at the moment:</p>
  
  <p>The DLL wrapper class constructor calls QCoreApplication::instance() to see if it's NULL or not.  If it's NULL, it assumes it's in a non-Qt app, and creates a QCoreApplication instance of it's own:</p>
  
  <pre><code>if (QCoreApplication::instance() == NULL)
  {
      int argc = 1;
      char* argv[] = { "dummy.exe", NULL };
      d-&gt;_app = new QCoreApplication(argc, argv);  // safe?
  }
  else
      d-&gt;_app = NULL;
  </code></pre>
  
  <p>It then will set up a windows timer to occasionally call processEvents():</p>
  
  <pre><code>if (eventTimerInterval &gt; 0)
  {
      // STATE: start a timer to occasionally process the Qt events in the event queue
      SetTimer(NULL, (UINT_PTR)this, eventTimerInterval, CDatabaseLayer_TimerCallback);
  }
  </code></pre>
  
  <p>The callback simply calls the processEvents() function using the timerID as a pointer to the class instance.  The SetTimer() docs say when HWND is NULL it ignores the timerID, so this appears to be perfectly valid.</p>
  
  <pre><code>VOID CALLBACK BLAHBLAH_TimerCallback(HWND hwnd, UINT uMsg, UINT_PTR idEvent, DWORD dwTime)
  {
      ((BLAHBLAH*)idEvent)-&gt;processEvents(); // basically just calls d-&gt;_app-&gt;processEvents();
  }
  </code></pre>
  
  <p>I then destroy the QCoreApplication instance as the very last thing in the destructor.</p>
  
  <pre><code>BLAHBLAH::~BLAHBLAH()
  {
      .. other stuff
  
     QCoreApplication* app = d-&gt;_app;
     d-&gt;_app = NULL;
     delete d;
     if (app != NULL)
         delete app;
  }
  </code></pre>
  
  <p>If the hosting application wishes to time the calls to processEvents() itself, it can pass 0 in for eventTimerInterval and call BLAHBLAH::processEvents() itself.</p>
  
  <p>Any thoughts on this?  Porting that app to Qt is not an option.  It's not ours.</p>
  
  <p>It appears to work, but there are probably several assumptions being broken here.  Can I just construct a QCoreApplication with dummy arguments like that?  Is the event queue safe to operate in this manner?</p>
  
  <p>I don't want this blowing up in my face later.  Thoughts?</p>