Comment puis-je associer une instance de plug-in Mozilla scriptable à son NObject?

Question

Je rencontre un problème en associant une méthode invoquée dans un plugin que j'écris avec l'instance de plugin appropriée. La documentation disponible sur http://developer.mozilla.org/en/Gecko_Plugin_APGIN_API_Reference/Scripting_plugins . ne donne pas assez d'informations pour être vraiment utile à ce sujet.

En résumé, j'essaie de comprendre quel objet de script le plug-in doit être renvoyé en réponse à un appel à NPP_GetValue avec un argument de variable égal à NPPpluginScriptableNPObject. Je suppose qu'il devrait y avoir une instance de NPObject pour chaque instance du plug-in, mais comment la méthode invoke () dans la classe NPClass est-elle supposée trouver l'instance de plug-in (NPP) à partir du NPObject scriptable qui lui est donné comme argument? Je suppose que je pourrais mettre en place une table de correspondance pour le faire, mais j’ai le sentiment qu’il manque quelque chose d’évident.

Je stocke un pointeur sur une instance d'une classe C ++ (l'instance implémente les fonctionnalités du plug-in) dans le membre pdata du NPP, dans NPP_New ().

Answer 1

Je suppose que je réponds à ma propre question ...

La solution que j'ai trouvée (et j'apprécierais tout de même les commentaires sur sa validité, surtout si vous pensez qu'il existe un meilleur moyen de le faire) consistait à allouer une structure dérivée de NPObject comportant un pointeur sur ma classe d'implémentation dans la méthode allocate (). fonction que j’expose à Firefox depuis mon plugin. Je stocke ensuite un pointeur sur ce NPObject dans le membre pdata du NPP, dans NPP_New ().

Dans invoke (), je transforme le pointeur NPObject aux membres supplémentaires de la structure dérivée, de manière à pouvoir obtenir un pointeur sur l'instance de la classe d'implémentation.

Cela, autant que je sache, est l’intention de la conception - les objets NPObject sont des instances de la classe NPC qu’ils désignent, ils implémentent des méthodes et des propriétés via les pointeurs de fonction NPClass qui traitent ces entités et toutes les données privées. devrait être alloué et désalloué par la mise en œuvre, et son format n'est pas spécifié.

Cela ressemblerait à quelque chose comme ça:

 static NPClass refObject = {
    NP_CLASS_STRUCT_VERSION,
    My_Allocate,
    My_Deallocate,
    NULL,
    My_HasMethod,
    My_Invoke,
    My_InvokeDefault,
    My_HasProperty,
    My_GetProperty,
    NULL,
    NULL,
};

class MyImplClass {
    // Implementation goes here
};

struct MyNPObject : public NPObject {
    MyImplClass *my_impl_instance;
};

// This is just a bit of memory management - Mozilla wants us to allocate our own memory:
NPObject *My_Allocate(NPP inst, NPClass *)
{
    // We initialize the structure in NPP_New() below
    return (NPObject *)malloc(sizeof(MyNPObject));
}

NPError NPP_New( NPMIMEType pluginType, NPP instance, uint16 mode, int16 argc,
             char* argn[], char* argv[], NPSavedData* saved )
{
    NPObject *scriptable_object = npnfuncs->createobject(instance, &refObject);
    npnfuncs->retainobject(scriptable_object);
    MyImplClass *new_player = new MyImplClass(); 

    instance->pdata = scriptable_object;
    ((MyNPObject*)instance->pdata)->my_impl_instance = new_player;
    return NPERR_NO_ERROR;

}