Starting C++ SDK Tutorial
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 10/02/2003 at 09:23, xxxxxxxx wrote:
Hi,
I'm referring to private plugin data stored within the document.PluginID values can be used to uniquely identify a subcontainer stored within an object's base container, in which the plugin can safely store arbitrary information for its own purposes.
My understanding is that this is the recommended method for storing such private information.
If another plugin uses the same ID value then both plugins would have access to the same subcontainer, but both would believe that it belonged to them only - as a result they could interact with each other in unpredictable ways.
In this way, different plugins _can_ mess up each others private data.
Cheers - Steve
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 10/02/2003 at 09:33, xxxxxxxx wrote:
I'm referring to private plugin data stored within the document.
PluginID values can be used to uniquely identify a subcontainer stored within an object's base container, in which the plugin can safely store arbitrary information for its own purposes.
--------------------------------------------
1. Could you explain that "subcontainer" method a bit more detailed? I didn´t know this is a prefered method for using "private" data... two or three lines of code explaining what you mean would be appreciated.
2. private data can´t be accessed by other plugins for it is declared as "private". Maybe you are talking something else?
--------------------------------------------My understanding is that this is the recommended method for storing such private information.
--------------------------------------------
I don´t think so. I have a thousand times the same IDs for basecontainer values in my plugins and none of them did ever collide. So I don´t get the point here really. Maybe someone from the dev support could help us find out what´s going on with stored data in basecontainers... But I can´t imagine it is possible.
---------------------------------------------If another plugin uses the same ID value then both plugins would have access to the same subcontainer, but both would believe that it belonged to them only - as a result they could interact with each other in unpredictable ways.
----------------------------------------------
Sorry, I don´t believe that. Then it would be easily possible to exchange data thru a subcontainer but afaik that´s not possible but only over the PluginMessage Port....?!
Best
Samir -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 10/02/2003 at 10:11, xxxxxxxx wrote:
Two plugins with the same plugin ID can -not- run at the same time.
However, lets say you have PluginA and PluginB, they both share the same ID (for whatever reason), a user creates a document with PluginA, sends this to someone with PluginB. When they open it, CINEMA will try and find the plugin with the matching ID that is of the same type, if say PluginA and pluginB are both plugin objects, then when PluginB tries to access the basecontainer data the values it reads back will make no/little sense to it, at best the plugin will just behave odd, at worst it could lead to serious problems (maybe a freeze or crash). This is the -only- way two plugins with the same ID could interact, plugins with different IDs (so they can run at the same time), can interact in many ways.
Sharing plugin IDs is NOT advised, they -must- be unique, if during development you use a set of fixed IDs or the temporary IDs, then that is your choice, I never do this, I'd rather start off with my real IDs.
BaseContainer data can be accessed by any plugin, there is no such thing as private, you don't even need to know the IDs of the data, you can enum the data elements.
You can use a subcontainer if you wish, but you don't have to, each type of object has its own basecontainer, the data is per object. Storing data in a BaseContainer is recommended simply because CINEMA will handle read/write and clone, if you have the data in your class then you need to handle the read/write/clone of any data the plugin needs.
I think there is some confusion in what you are both talking about, I couldn't really follow either of you
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 10/02/2003 at 10:17, xxxxxxxx wrote:
BaseContainer data can be accessed by any plugin, there is no such thing as private, you don't even need to know the IDs of the data, you can enum the data elements.
You can use a subcontainer if you wish, but you don't have to, each type of object has its own basecontainer, the data is per object. Storing data in a BaseContainer is recommended simply because CINEMA will handle read/write and clone, if you have the data in your class then you need to handle the read/write/clone of any data the plugin needs.
-------------------------------------------
Ah ok, this makes things clearer. Thanks for clarification.
-------------------------------------------
I think there is some confusion in what you are both talking about, I couldn't really follow either of you
-------------------------------------------
lol, I didn´t even know myself what we were talking.
Best
Samir -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 10/02/2003 at 12:26, xxxxxxxx wrote:
David: The A/B plugin situation you described was what I meant regarding potential conflict between plugins - but you explained it much more clearly!
3D: Ok, I shouldn't really have referred to it as 'private', because it's not actually private - it's just data that is only _meant_ to be accessed by one particular plugin. There isn't actually anything to stop it though.
From the SDK (R7 and R8), under 'BaseContainer':
"It is recommended that you use the available containers to store your own values as well. That way they will be automatically saved. However, if you want to store values in the top level of for example an object container, you'll have to use a unique id. You can use a plugin id from http://www.plugincafe.com for this. A good way is to store a sub-container with this id. Inside this sub-container you can use whatever ids you want."If you follow this advice, and use the PluginID as a unique ID number to identify 'your' sub-container, then the A/B situation David described means that one plugin could see the sub-container that the other one wrote, and chaos _may_ then ensue...
One final note - the docs say that using a plugin ID number is a good way of getting a unique number. It seems to me that it is the _only_ way of getting a number that you know is unique.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 10/02/2003 at 12:46, xxxxxxxx wrote:
well, that is a difference to me. Me, I never use already available Object Containers (except of my own plugin)! For example a light container or anything. This is a difference to what I thought we were talking about! But to be honest I never new they were called subcontainers, so in this point you trapped me.
But as Dave said, there won´t probably be a plugin that will be able to use specific data from another plugin. And by the way, how does this topic came up? Did anybody not use a unique ID? Sorry, haven´t read the whole thread...but I agree to your last statement.
But you should concentrate on other things than plugin IDs. Me I have to use it elsewhere than in the registration method only once in a lifetime. And now that we got the AM it is even less necessary. -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 10/02/2003 at 14:11, xxxxxxxx wrote:
A comment about putting plugin IDs in the c4d_symbols.h header file, and the risk that the user would change them. This is not a problem with C++ plugins, since the value is stored during compilation, like a #define. (C.O.F.F.E.E. plugins are loaded dynamically, though.)
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 11/02/2003 at 13:06, xxxxxxxx wrote:
Hi Mikael,
yep you're right. And now I rememer again, that was the cause, why I put the plugin ID into the symbol file: That way everybody is able to read the ID. -> I will keep his approach.
Ciao and happy hacking,
Marcus -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 12/02/2003 at 02:44, xxxxxxxx wrote:
Ok, good point about the c4d_symbols.h being compiled in to the plugin. So the risk of conflicting plugin IDs being created by the end user (for C++) shouldn't be an issue.
I still don't think that it's a good idea to put the ID in the file, though:
1. No users should need to know the plugin ID.
2. There's no guarantee that the number in the file matches what the plugin ID actually is. I.e. if at some point after the plugin has been built this number is changed, nothing will break but the information will be inconsistent. That is not a good thing.Scenario:
Somehow two plugins with conflicting ID numbers are created, and they both have the ID number listed in the 'c4d_symbols.h' file. Anyone seeing this could reasonably assume that by changing one of them they could resolve the conflict - but it won't (unless it's a Coffee plugin), so they're likely to assume that something else is causing the problem and start looking for other problems that don't exist...I know that this is an unlikely situation, BUT, I've spent enough time programming to become very keen on defensive programming techniques, and this looks like something that is a bad idea. It makes it look like people can change something when they can't.
Cheers - Steve
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 12/02/2003 at 02:58, xxxxxxxx wrote:
1. No users should need to know the plugin ID.
---------------------------------------
Some users will know anyway for i.e. Object or tag plugins.
->Create COFFEE Expression on pluginobject or object with plugintag(expression) ->use println(op->GetType()) or println(op->GetFirstTag()->GetType());
Hello, there is the plugin ID.
The user shouldn´t be able to change the plugin ID but it´s not dangerous if he knows it (except he then creates a plugin with the same ID on purpose
Best
Samir -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 23/02/2003 at 15:42, xxxxxxxx wrote:
Hi Folks,
I've put the stuff Sneaker and I have done together on a web-page - with some additional information. And currently I'm working on a description for a EdgeFlip plugin. For those who can't wait, I've put it's sources online. The documentation will follow this or next week - depending on my spare time.
And I have to excuse my little English skills - but I hope it's understable.
Here is the (preliminary) link to the web-page:
http://home.arcor.de/marcus.spranger/sdk8_pool/Ciao,
Marcus