I'm writing an NPAPI plugin in C++ on Windows. When my plugin's instantiated, I want to pass it some private data from my main application (specifically, I want to pass it a pointer to a C++ object). There doesn't seem to be a mechanism to do this. Am I missing something? I can't simply create my object in the plugin instance, since it's meant to exist outside of the scope of the plugin instance and persists even when the plugin instance is destroyed.
Edit:
I'm using an embedded plugin in C++ via CEF. This means that my code is essentially the browser and the plugin. Obviously, this isn't the way standard NPAPI plugins behave, so this is probably not something that's supported by NPAPI itself.
You can't pass a C++ object to javascript; what you can do is pass an NPObject that is also a C++ object and exposes things through the NPRuntime interface.
See http://npapi.com/tutorial3 for more information.
You may also want to look at the FireBreath framework, which greatly simplifies things like this.
Edit: it seems I misunderstood your question. What you want is to be able to store data linked to a plugin instance. What you need is the NPP that is given to you when your plugin is created; the NPP has two members, ndata (netscape data) and pdata (plugin data). The pdata pointer is yours to control -- you can set it to point to any arbitrary value that you want, and then cast it back to the real type whenever you want to use it. Be sure to cast it back and delete it on NPP_Destroy, of course. I usually create a struct to keep a few pieces of information in it. FireBreath uses this and sends all plugin calls into a Plugin object instance so that you can act as though it were a normal object.
Relevant code example from FireBreath:
https://github.com/firebreath/FireBreath/blob/master/src/NpapiCore/NpapiPluginModule_NPP.cpp#L145
Pay particular attention to NPP_New and NPP_Destroy; also pay particular attention to how the pdata member of the NPP is used.
This is also discussed in http://npapi.com/tutorial2
There is no way to do this via NPAPI, since the concept doesn't make sense in NPAPI terms. Even if you hack something up that passes a raw pointer around, that assumes everything is running in one process, so if CEF switches to the multi-process approach Chromium is designed around, the hack would break.
You would be better off pretending they are different processes, and using some non-NPAPI method of sharing what you need to between the main application and the plugin.
Related
The DYNAMIC FACTORY pattern describes how to create a factory that
allows the creation of unanticipated products derived from the same
abstraction by storing the information about their concrete type in
external metadata
from : http://www.wirfs-brock.com/PDFs/TheDynamicFactoryPattern.pdf
The PDF says:
Configurability
. We can change the behavior of an application by just changing its configuration
information. This can be done without the need to change any source code (just change the descriptive information about the type in the metadata repository) or to restart the application (if caching is not used – if caching is used the cache will need to be flushed).
It is not possible to introduce new types to a running C++ program without modifying source code. At the very least, you'd need to write a shared library containing a factory to generate instances of the new type: but doing so is expressly rules out by the PDF:
Extensibility / Evolvability
. New product types should be easily
added without requiring neither a
new factory class nor modifying
any existing one.
This is not practical in C++.
Still, the functionality can be achieved by using metadata to guide some code writing function, then invoking the compiler (whether as a subprocess or a library) to create a shared library. This is pretty much what the languages mentioned in the PDF are doing when they use reflection and metadata to ask the virtual machine to create new class instances: it's just more normal in those language environments to need bits of the compiler/interpreter hanging around in memory, so it doesn't seem such a big step.
Yes...
Look at the Factories classes in the Qtilities Qt library.
#TonyD regarding
We can change the behavior of an application by just changing its configuration information.
It is 100% possible if you interpret the sentence in another way. What I read and understand is you change a configuration file (xml in the doc) that gets loaded to change the behaviour of the application. So perhaps your application has 2 loggers, one to file and one to a GUI. So the config file can be edited to choose one or both to be used. Thus no change of the application but the behaviour is changed. The requirement is that anything that you can configure in the file is available in the code, so to say log using network will not work since it is not implemented.
New product types should be easily added without requiring neither a new factory class nor modifying any existing one.
Yes that sounds a bit impossible. I will accept the ability to add ones without having to change the original application. Thus one should be able to add using plugins or another method and leave the application/factory/existing classes in tact and unchanged.
All of the above is supported by the example provided. Although Qtilities is a Qt library, the factories are not Qt specific.
I have looked at multiple sources and I just do not understand them. Mostly all of them are either using a library like luaBind (Which I do not want to use because it relies on Boost) or they are not already instanced objects in C++ but rather created in Lua directly.
I have a Player class, which is wrapped in another class to handle Lua calling. I have created a std::vector list of both these objects in my initialization of the application.
So basically I do not want the Lua script to be creating these player objects I would just like to create a function getPlayer() which then returns the Lua wrapped object. I have no idea where to start with defining the Lua wrapped object for Lua to call nor do I know how to return an instance of the object to Lua so I can use calls from it.
Here's an example of what I would like my Lua script to look like:
player = getPlayer(1) -- Returns the Lua wrapped object from C++ where 1 is the object's index in the std::vector list
print("Player's name: ", player:name()) -- Print's the player's name
Could someone point me to a decent tutorial that explains how to do this. I am pretty sure that this isn't some sort of "Never been done and why would you want to" case so surely there must be at least one tutorial out there. I have been searching for about 2 days now with no positive results.
This isn't a Never been done task, but companies which they use Lua have been already done lots of changes and improvements on the raw source of Lua to make it fit in the place that they want. Since all of us programmers are not that cool to do such stuffs on third-parties sources, we have to use whatever exists out there. You think Crytek is using the exact same version of Lua which is resided on its website's repository? No sir.
You can make this happen by using userdata. Or you can use meta tables. There is also another piece of code named Luna which it helps you to achieve faster.
Otherwise, it's all Luabind, and believe me you're going to end up using it one way or another. Besides, its use of Boost is not that broad and there is going to be just 200kb added to the final executable. Check this address if you want to use Luabind sometime, it's really a good article on the web. http://blog.nuclex-games.com/tutorials/cxx/luabind-introduction/
If you're too bored with Lua, I may suggest you to use squirrel as an alternative to Lua. Personally, I prefer squirrel more than Lua because of its C like syntax and its abilities which they are the ones that we want. Besides, you can even declare constants and use real classes in its context which Lua is pretty failed at this. The funny thing about squirrel is that the designer is a guy that he has been working on FarCry on developing Lua for its engine.
DirectX 9 / C++
Do you declare d3ddevice global to your entire app/game or do you pass into classes that require the d3ddevice?
What is the usual way?
I understand it (and this may be wrong) that if you declare it globally, all classes and functions will be burdened by header memory that declares that global variable within the class after compiling?
I can be more specific about my question my application but, I'm just looking for the typical way.
I know how to start the d3ddevice etc, it's just a question about what is best?
I would recommend you wrap everything within a class and never put anything in global because global variables can be accessed from anywhere and that can make it very hard to keep track of the variable and who is and isn't using it.
Little bit late to the party here, but I also just recently stumbled into this same design question. It's a little surprising to me that there isn't more talk about it on the internet. I even tried perusing random github libraries to see if I could glean how others did it. Didn't find much. I also have an example of when you can't declare the d3d device as a global/static object. For my game/engine, I have a dll which serves as my engine framework. This dll is consumed by both an editor, and a game client (what people will use to play my game). This allows both things (and other applications in the future if desired) to access all of the world objects, math code, collections, etc.
With that system, I can't think of a way to make the Device object static, and still use it in both the editor and the client. If this were just a game client, or just an editor, then sure, it would be possible. Instead, I've pretty much decided to bite the bullet and pass Device to whatever needs it. One example, is a class that generates vertices at runtime. I need a pointer to Device for rebuilding the class.
I really just wanted to post this here, because I've been thinking about it for most of the day, and it really seems like this is the best way to handle it. Yeah, it sucks to have to pass the Device to nearly everything. But there's not really anything you can do about it.
In our company we're using a plugin system that I've written using QT plugin system.
Each plugin has "needed functions" and "own functions" so, if a plugin needs a function called *func_1*, there must be a plugin that has a function called *func_1*.
This works great, but now I have a problem: a plugin needs to know the pointer to a certain class object that another plugin uses but that is external. I cannot put any kind of information about this class in the plugins interface as it has nothing to do with it.
The only solution I have, is to write a interface function with which I can pass void pointers, but I'd like to know if there's other solutions maybe less C style.
Thanks in advance.
The modern C++ "replacement" for a void-pointer is something like Boost.Any. It'll allow you to pass anything through the interface, and still gives you a certain type-safety.
I need to implement a bare-bones COM object in straight C++ (no ATL) that is used by a legacy web application to check that my application exists. The web application does something like this (JavaScript):
var object = new ActiveXObject("My.Application");
I want to ensure that the above succeeds but thats all I need to do - I do not need to implement any methods/properties on this object as they are never called.
Obviously I need to ensure that my object is registered by adding the necessary registry settings, etc. My application is a DLL so I guess I also need to implement a handful of exported functions (DllRegisterServer, DllUnregisterServer, DllCanUnloadNow and, the one that has to so something, DllGetClassObject).
I'm pretty sure that simply returning S_OK from DllGetClassObject won't cut it.
How can I go about implementing a basic interface without using ATL? I am using the MS compiler if that helps.
It's not sufficient to build a bare-bones COM object. For starters, that would be so bare-bones that there's no name associated with it. You've already discovered that you need an object factory, too.
So, yes, implement DllGetClassObject. You'll have to check the input rclsid argument. This is an interface identifier. If you don't recognize it, return CLASS_E_CLASSNOTAVAILABLE. Apparently, because of hackerish approaches (like the unconditional S_OK you suggested) Microsoft now passes at least one invalid class ID.. If you lie, and claim you can do it, Windows will not believe anyhting else you say.
So, what interfaces should you claim? Obviously IUnknown - it's the very root of the system. The most bare-bone COM object doesn't do anything else. You need more interfaces, though - the web app is asking for an ActiveX object. That requires more interfaces. Possibly the easiest approach would be to just see what Windows is asking for. I suspect you'll need at least IDispatch.
Next, you'll have to implement a few methods. "Wait", you may say, "they're not called". Well, IDispatch is a kind of meta-interface for scripting langauges. It's used to enumerate which methods are available. Hence, your IDispatch interface should support such enumeration as well, even though it would return zero scriptable methods.
There's a lot more detail, but this should already be sufficient to help convince you to use ATL and grab its ActiveX code. That's going to be far more complete than anything I can list here.
There is nothing bare-bones about a COM server that supports late binding from Javascript running inside IE. If you don't know how to implement DllGetClassObject() then you need all the help you can get. You get a lot of help from ATL and the wizards built into Visual Studio. The vast majority of the fugly plumbing code is auto-generated, including those 4 exports. And IDispatch, the interface that the Javascript needs.
Start the project with the ATL + ATL Project template. The defaults are good. Right-click the project, Add, Class and select ATL + ATL Simple Object. Switch to Class View, locate your interface type and right-click it to add methods and properties.