Hi, Sorry for the delay, I was busy with the development of Mac version of the plugin so couldnt test this. Finally, facing the same problem with Invoke in a different place.
Let me explain my code properly.
In the onWindowAttched event, I create the opengl thread and my mainApplicationPtr object pointer. mainApplicationPtr is object of MainApplication which is responsible for managing my plugin logic. All opengl calls are done from the mainApplication->update() function. I also pass the FB::JSAPIPtr apiPtr into my mainApplicationPtr so that it can Invoke JS functions when required. I reset this apiPtr in onWindowDetach event where my mainApplicationPtr pointer is also deleted.
Opengl thread goes something like this -
LPTHREAD_START_ROUTINE SamplePlugin::drawThreaded( LPVOID lpParam )
{
FBLOG_INFO("drawThreaded", "Initializing OpenGL Thread.");
EnableOpenGL( pluginWindowWin->getHWND(), &hDC, &hRC );
SetFocus(pluginWindowWin->getHWND());
enableEvents = true;
pluginRunning = true;
while(run & !stopThread)
{
try
{
FB::Rect pos = pluginWindow->getWindowPosition();
#if FB_WIN
// HDC hDC;
// FB::PluginWindowlessWin *wndLess = dynamic_cast<FB::PluginWindowlessWin*>(pluginWindow);
// FB::PluginWindowWin *wnd = dynamic_cast<FB::PluginWindowWin*>(pluginWindow);
// The PAINTSTRUCT structure contains information that can be used to paint the client area of a window.
PAINTSTRUCT ps;
if(pluginWindowWin)
{
// The BeginPaint function prepares the specified window for painting and fills a
// PAINTSTRUCT structure with information about the painting.
hDC = BeginPaint(pluginWindowWin->getHWND(), &ps);
if(initializeFlag)
{
{
boost::recursive_mutex::scoped_lock lock(openglThreadMutex);
mainApplicationPtr->initialize();
initializeFlag = false;
}
std::vector<FB::variant> argsEmpty;
argsEmpty.push_back("Successful");
apiPtr->Invoke("initializedCallback", argsEmpty);
}
{
boost::recursive_mutex::scoped_lock lock(openglThreadMutex);
mainApplicationPtr->update();
}
SwapBuffers( hDC );
}
if (pluginWindowWin)
{
// Release the device context
EndPaint(pluginWindowWin->getHWND(), &ps);
}
#endif
//return true;
}
catch(...)
{
FBLOG_INFO("ThreadError", "Error occurred in opengl thread");
return 0;
}
Sleep(10);
}
FBLOG_INFO("drawThreaded", "Breaking out of thread!");
return 0;
}
I have exposed a JSAPI function named insertImageUsingUrl(url) which is used to load image into the plugin using its url. This JSAPI function internally calls a function with same name(insertImageUsingUrl) from MainApplication class(i.e. mainApplicationPtr->insertImageUsingUrl(std::string url)). This function downloads the image asynchronously and when the download is complete, it sets a bool named insertImageFlag to true. MainApplication's update function checks for this variable, if this is set to true, it creates opengl texture from the downloaded image. After this it Invokes - imageInsertedCallback. It is at this Invoke when the plugin hangs.
On my webpage, in the onload function I check if the plugin is installed or not. If it is installed, I insert the plugin object into the page. I also add the event initializeCallback to the plugin object in javascript. And this callback goes something like this in javascript,
addEvent(plugin(), 'initializeCallback', function(msg)
{
plugin().insertImageUsingUrl("...");
}
When the plugin is initialized successfully, I insert image into it.
When I try to Invoke imageInsertedCallback, the plugin hangs in this line while locking m_zoneMutex -
FB::variant FB::JSAPIAuto::Invoke(const std::string& methodName, const std::vector<variant> &args)
{
boost::recursive_mutex::scoped_lock lock(m_zoneMutex);
...
}
m_zoneMutex shows that I has been locked by the mainThread, and then it hangs but all my Invoke calls are from my opengl thread.
I'm really out of ideas to solve this problem.
@John Tan: Could you please shed more light on how to implement callbacks using boost::bind and boost::function.
--
---
You received this message because you are subscribed to the Google Groups "firebreath-dev" group.
--
---
You received this message because you are subscribed to the Google Groups "firebreath-dev" group.