THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 17/03/2006 at 10:32, xxxxxxxx wrote:
User Information:
Cinema 4D Version: 8.2+
Platform: Windows ; Mac ; Mac OSX ;
Language(s) : C++ ;
---------
Howdy,
I notice that the R9 AtomArray has Append() and Remove() functions, where the R8 AtomArray only has the Append() function. Is there a work around for getting R8 to remove the object from the AtomArray?
Adios,
Cactus Dan
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 18/03/2006 at 21:36, xxxxxxxx wrote:
Hi Dan,
After looking at the AtomArray class in R8, it looks like you'll have to be inventive. My thought was to create a new AtomArray and Append() the elements from the old one into it, skipping the ones you want to remove. Not very eloquent, but I don't see an alternative.
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 19/03/2006 at 08:45, xxxxxxxx wrote:
Howdy,
Oh well, I may end up not supporting R8 for certain plugins, if there are no easy work arounds for the R8 SDK limitations.
Adios,
Cactus Dan
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 19/03/2006 at 09:35, xxxxxxxx wrote:
Hi,
without knowing the conditions of where you use the AtomArray, why not holding a seperate array of indices that are not used. That way you can skip those indices that are not existant any longer when you iterate thru the AtomArray for example.
Or write your own AtomArray class.
HTH
Samir
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 19/03/2006 at 11:40, xxxxxxxx wrote:
That would possible, but some work. You couldn't use BaseDocument::GetActiveObject() or ::GetActiveTags(). Instead, you'd need to implement your own to go through the document and retrieve them to store in the new AtomArray class. Shouldn't be too difficult.
Whether to use your own list maintenance or BaseList2Ds will need to be considered.
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 19/03/2006 at 12:46, xxxxxxxx wrote:
Why couldn´t you use GetActiveObject/GetActiveTags any longer?
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 19/03/2006 at 14:21, xxxxxxxx wrote:
Um, because if he implements his own 'AtomArray' class, I don't think BaseDocument is going to be fooled since you usually pass the standard SDK AtomArray class with these methods. ;)
P.S.: That was supposed to be GetActiveObject***S***!
Now, he could modify the SDK directly and replace the current AtomArray class, but isn't that going too far? And there is no guarantee that missing one iota of detail not revealed by C4DDos will not lead to continuous crashing.
ETA: (Isn't trying to read into text lovely? ;) - If you mean "Why couldn't he continue using standard AtomArray to call GetActiveObjectsss(), GetActiveTags(), and GetActiveMaterials()?", well he could. But if you're going to do that, what's wrong with my first suggestion? Less work and nearly identical (you still need to allocate an AtomArray and allocate your AtomArray replacement)!
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 19/03/2006 at 15:25, xxxxxxxx wrote:
Howdy,
Well, the use of the AtomArray is to keep a list of all of my plugin's tags in the document, so that I can send a message only to them when an update is needed (thanks to Paul Everett for showing me how to do that).
When a tag is added to the document, the Init() function does an Append() to the AtomArray, and when the tag is deleted from the document, the Free() function does a Remove() from the AtomArray.
So when it comes time to send the message it's doing this:
LONG i, tCnt = d.list->GetCount();
for(i=0; i<tCnt; i++)
{
BaseTag *tag = static_cast<BaseTag*>(d.list->GetIndex(i));
if(tag->GetDocument())
{
tag->Message(MY_MSG_UPDATE);
}
}
...so it does need to retrieve a pointer to a BaseTag so it can then send the message.
Only supporting R9 isn't really a problem because R10 is probably just around the corner anyway. I just thought it curious that R8's AtomArray only had an Append() function, and not a Remove() function.
Unless, constantly appending the AtomArray without removing any members is no big deal? I mean, since the AtomArray is not saved with the file and is recreated everytime you load the file, so that the next time you load the file, those tags that were deleted won't be appended to the AtomArray upon loading, right?
Adios,
Cactus Dan
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 19/03/2006 at 17:53, xxxxxxxx wrote:
The only way your AtomArray will be saved and reloaded with the document is if you do so in implemented Read/Write/CopyTo methods.
Where is the AtomArray class stored? I take it that since it tracks your tags in the document, it is either in some other of your plugin tags or objects. (?)
Also, are you attempting to modify the AtomArray in the tag being added/removed (via Message())?
Would need to see the circumstances to say whether or not juggling class instances on a pointer would be justified.
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 19/03/2006 at 19:02, xxxxxxxx wrote:
Howdy,
Oh no, I don't need to save the AtomArray to the hyperfile, it is only there to keep a running list of which tags to send the message to. The message is being sent from a MessageData() which is polling for the core message EVMSG_CHANGE. Then it resends a custom message, only to the plugin's tags so they can check their data to see if they need to update.
Each time you load the file the tag's Init() function will be called and the tag is appended to the AtomArray, so the AtomArray gets rebuilt each time the file is loaded.
In the Main.cpp file, it's defined like this:
static AtomArray *taglist = NULL;
Then the AtomArray is allocated in PluginStart() :
taglist = AtomArray::Alloc();
and freed in PluginEnd() :
AtomArray::Free(taglist);
Then a case is added in PluginMessage(LONG id, void *data) :
case ID_MYTAG:
d = (mydata * )data;
d->list = taglist;
return TRUE;
The data structure is set up in the plugin's header file like this:
struct mydata
{
mydata(){list=NULL;}
AtomArray *list;
};
Then the pointer to the AtomArray is obtained from the tag's Init() function by sending:
mydata d;
PluginMessage(ID_MYTAG,&d;);
... which returns the pointer to the data structure "d" so it can append the array like this:
if(d.list) d.list->Append(node);
Then, in the tag's Free() function it removes the node from the AtomArray like this:
mydata d;
PluginMessage(ID_MYTAG,&d;);
if(d.list) d.list->Remove(node);
The code is from Paul Everett, who helped me set it up and it works great, but when I went to recompile it in R8, that's when I discovered that the R8 AtomArray class doesn't have the Remove() function available.
But, I'm curious if in R8, you can get by without the Remove() function, because the code in the MesageData() is checking if the BaseTag has a document before it tries to send a message to the tag. I may not support R8 for the plugin anyway, but was just curious.
Adios,
Cactus Dan