0

I have an ActiveX dll that loads a child dll (NPAPI plugin). My child plugin creates multiple threads and they need to communicate back to the web page. In my ActiveX (parent dll) I have connection points to fire an event for javascript to provide updates. The problem I am having is that I do not know how the child can call the parent DLL.

What I have tried: 1: Passing a function pointer to the child dll of a function that is not within the class and used a global variable that is a pointer to the ActiveX class (this), but the connection point fails when Invoke with E_UNEXPECTED

2: Passing the child dll a pointer to my class function, and get the same results.

Im still learning C++ and COM at the same time, sorry for my ignorance. Thank you.

hapyfishrmn
  • 177
  • 2
  • 21

1 Answers1

0

COM has ways to set things up so that you can call COM methods from other threads, but the easiest way for you to do this would be to make all calls back to the activex control on the main thread. One way to do this is to create a Message Window and post a windows message to it with the LPARAM being a pointer to a data structure containing the parameters needed to make the call; you create the structure and fill it out, then post the message and free the memory after your WINPROC has made the call.

FireBreath uses this approach and it works quite well. Speaking of which, have you considered implementing your NPAPI plugin as a FireBreath plugin so that it works in both activex and npapi?

Here are some code samples that may help:

  • WinMessageWindow (.cpp, .h) - this is a class FireBreath uses for creating message windows; pay particular attention to the DefaultWinProc which is used as part of an async (often cross thread) function call
  • NpapiBrowserHostAsyncWin (.cpp, .h) - this is a class used on some browsers for the npapi plugin to work around NPN_PluginThreadAsyncCall not working. It utilizes WinMessageWindow to make cross thread calls in _scheduleAsyncCall

Hope that helps

taxilian
  • 14,229
  • 4
  • 34
  • 73
  • Maybe I should edit the question. I am trying to have ActiveX call Javascript function. – hapyfishrmn May 17 '12 at 20:41
  • You are welcome to edit it, but my answer will not change; this is how FireBreath makes calls to Javascript on IE. – taxilian May 17 '12 at 20:47
  • I am trying to have ActiveX call Javascript function. In my ActiveX I have a class CSample and a connection point in the class called Fire_Update (which fires an event that js picks up). As long as I am within the class I can call Fire_Update, but my child dll spawned threads and needs to call the update. How do I communicate back to the class. – hapyfishrmn May 17 '12 at 20:52
  • Following the suggestions I made above; when you need to make a function call, you put the data in a structure and fire a message to the message window which you created before anything spawned any threads. The WINPROC for that window receives the message and makes the function call that you wanted to make. The message will arrive on the main thread, thus it is safe to make the call from there. – taxilian May 17 '12 at 20:57
  • I implemented a Message proc like you have in your example (WinMessageWindow), but can't call Connection point events from a static function. I tried saving the pointer of the class as a global and tried calling the events but there is no connection. What could I be missing? – hapyfishrmn May 22 '12 at 14:16
  • Store everything you need for making the call in a structure of some sort (we use the AsyncFunctionCall pointer in Firebreath which you can find if you look) and pass a pointer to that structure as the lparam as seen in the WinMessageWindow. – taxilian May 22 '12 at 16:02
  • I did pass the pointer to the class (this) and userData in a structure, but the same results are no connections when I enter the Fire_update event. I can call the events (Fire_update) outside of the window proc in a class::method situation, just not this one. – hapyfishrmn May 22 '12 at 19:11
  • This is not something I can debug for you in comments =] I don't have nearly enough information to do more than hypothesize. Most likely if you can't access the COM interfaces then you aren't on the right thread which means the message window wasn't created on the correct thread. – taxilian May 22 '12 at 21:18