Certainly :)
Window messages aren't yet installed, but when they are I'll put them up here.
I am fixing my crashing when calling NPAPI functions in a rather messy fashion, in the hopes of eliminating the need to actually figure out what is going wrong. ( Whatever it is looks to me as though it crashes before the bit of code that actually recievs and processes function calls :S )
The current setup for my messaging system is such as this:
(ghEmbedder.dll)
//This should be an external file, but is not.
//Constants/Structs known by both ghMain and ghEmbedder
const int msgNPN_GetURL=1;
const int msgNPN_NewStream=2;
const int msgNPN_PostURL=3;
const int msgNPN_Write=4;
const int msgNPN_RequestRead=5;
const int msgNPN_DestroyStream=6;
const int msgNPN_ReloadPlugins=7;
const int msgNPN_SetValue=8;
const int msgNPN_Status=9;
struct GetURLMsg{
char url[255]; //I recall that the maximum URL length is 255
char target[128]; //Anyone with a target id over 128 characters deserves a crash
} ;
//NPAPI Browser-Side Functions
EXPORT void _stdcall ghWriteStatusBar( const char* text )
{
COPYDATASTRUCT data;
data.dwData=msgNPN_Status;
data.cbData=strlen(text)+1; //+1 to include NULL character. DON'T DO THE SAME MISTAKE I DID!
data.lpData=(PVOID)text;
SendMessage((HWND)parentHWnd,WM_COPYDATA,(WPARAM)(HWND)embedHWnd,(LPARAM)(LPVOID)&data);
}ghMain then recieves these messages through its window event handler and processes the functions they relate to.
My solution is to have PluginHostCtrl redirect any window messages sent to ghMain to go straight to itself, thus defeating glitches from whatever it was doing before.
First, however, I have another odd occurence to check out... which is that I sense window messages aleady being used to do all this stuff!
I may be wrong, but I'll soon see. It's either good or bad... (I don't really know much about how this thing works, but I may be learning something from this).
I am suspecting this because of the following:
#define WM_NPP_NEWSTREAM WM_USER
#define WM_NPP_DESTROYSTREAM WM_USER + 1
#define WM_NPP_URLNOTIFY WM_USER + 2
#define WM_NPP_WRITEREADY WM_USER + 3
#define WM_NPP_WRITE WM_USER + 4
#define WM_CLASS_CLEANUP WM_USER + 10
#define WM_CLASS_CREATEPLUGININSTANCE WM_USER + 11
Perhaps there is a disagreement in NPAPI versions here causing the crash, or IE just doesn't like this thing.
Etiher way, a little rewrite in the handler here may work wonders, since I am still thinking of something slightly different, and it probably wouldn't hurt. (Now... if only this source code had comments telling me what these files all do...)
Edit: Actually, I am now almost sure that window messages are not used to bounce functions around, but that these variables may be used by NPAPI itself... Or perhaps they are something that I don't need to think about.
Am I right in assuming that npn.cpp is where all the handling of functions happens, and npn.h deals with functions handed down to the NPAPI plugin?
A quick search for "callbacks" in the project gives me few results, with the most prominant being:
typedef NS_4XPLUGIN_CALLBACK(NPError, NP_GETENTRYPOINTS) (NPPluginFuncs* pCallbacks);
typedef NS_4XPLUGIN_CALLBACK(NPError, NP_PLUGININIT) (const NPNetscapeFuncs* pCallbacks);
typedef NS_4XPLUGIN_CALLBACK(NPError, NP_PLUGINSHUTDOWN) (void);
So it looks like I'm dealing with something more fancy here, which is also probably more likely to mess up.
Would I be right in wagering that this is a problem created by some recent Windows security stuff?
Oh, and My email addy is in my profile.
Meh, I hate sending people on tedious link journeys: DylanMcCall@... :)
Edit:
EEk! Sorry that this post doesn't make much (or any) sense. I was thinking while writing, and editing thoughts into nearly random places.