THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 28/09/2008 at 09:17, xxxxxxxx wrote:
Cinema 4D Version: 9.6+
Platform: Windows ; Mac ; Mac OSX ;
Language(s) : C++ ;
Ok, I haven't actually tried running this yet, because it occurs to me that I have a race condition. Here's the situation...
I have some tags that are now 'obsolete' and I want to replace them with the newer tags. I _could_ do this with a separate Command plugin (which would be easy), but:
- for the tags to still be 'valid' (ie. get loaded, along with thier containers with saved scenes that have them in it), the old plugin handlers (for those plugin IDs) need to exist and be registered.
- given the above, I still want to indicate the user should (be forced to, even) fix up/replace those tags with the new ones.
- only my BETA testers will have these (now obsolete) tags, so I didn't want to merge a new plugin into the release version.
...My idea is to replace the operational code of the obsolete tags (thier 'Edit' function) with code that replaces the old tags in the scene with the new ones (Remove()/Free() old ones, Insert() new ones with the data copied/ported over).
Of course the problem with that is that the tag that gets clicked on to DO this operation should/could probably not be Free()'d, because it's code is currently being executed. To get around this, I coded it to just GePluginMessage() me and have my PluginMessage() handler do the replacement, but it just occured to me that that didn't really fix anything relative to the race-condition (if the plugin handler sends a message, I believe that that's still a 'modal' operation, so my PluginMessage() handler code would still be trying to execute within the call to my plugin handler code (?)).
I think I'm probably answering my own question as I type this... I think I'll probably end up:
- writing a simple stand-alone Command plugin, to give to the testers.
- replace the icon of the obsolete tags with something distinctive.
- replace the operational code of those plugins with a simple dialog, telling them to run the other plugin.
...I was just hoping to avoid going that route, because the stand-alone plugin will have limited use, but someone may find/load a file that needs fixing a year from now that they forgot about and may have long-ago deleted that plugin. If the code was built in to the tag itself, that wouldn't be an issue.
Any thoughts on how to have a tag remove and free itself? I guess I could just check the address and not try to free whatever tag was doing the removal and freeing... ie. let the user delete that one himself (?).
On 28/09/2008 at 09:33, xxxxxxxx wrote:
...just to clarify, for the curious, the tags in question are the Group, Region and Export Mask tags of Riptide. I am currently getting ready to release Riptide Pro and as originally implemented, I created 'new' plugin IDs for those tags (so that I could have both Riptide and Riptide Pro installed at the same time).
As I was writing the documentation for Riptide Pro , it occured to me that having those tags use new IDs was a bad idea - the new plugin knew to look for and could handle the old (or new) IDs, but it 'created' only new ones, so any .c4d files saved would require Riptide Pro (free Riptide doesn't know to look for the new tag IDs).
Of course that's not a terrible situation (might help drive Riptide Pro sales ), but the functionality and structure of those tags didn't change, so I'd like to keep down the added confusion with distributed .c4d files relative to which plugins are required to open them... ie. I'm switching back to the older free Riptide IDs for those tags.
On 28/09/2008 at 20:29, xxxxxxxx wrote:
Well, I don't know if this would be an acceptable solution for you or not, but could you have both tags in each plugin, and then check for which version of the plugin is installed. Then if the pro version is installed, the free version tag is registered as a hidden tag, and does nothing. And if the plugin is the free version, the pro version tag is registered as a hidden tag and does nothing.
Would that work?
On 28/09/2008 at 23:20, xxxxxxxx wrote:
Yeah, I've considered doing something like that - and still might. It's just not as 'clean' a solution as I'd hoped... since there's only a handfull of testers who'd even have the problem, I think I'l still work towards just getting them fixed.
The simplest solution may still just be a stand-alone Command plugin, or one built-in, that could be disabled - or disabled by default - and then 'enabled' by the testers, similar to how the SDK samples load or not, based on the name string existing. That way, they could fix thier files and then disable it until/unless it was needed later.
Thanks for the input.
On 29/09/2008 at 01:14, xxxxxxxx wrote:
Well if I understand it correctly this only would affect scenes created by your beta testers? If so I am not sure if it is worth going through all this hassle.
On 29/09/2008 at 02:01, xxxxxxxx wrote:
That's correct. And... the tags are easy enough to recreate manually anyway, but that might be painfull if someone has a scene with many dozens of these tags in it - there can only be one of each of those 3 tags on any object, but someone might have some scenes with dozens of objects.
On the other hand, a stand-alone plugin is easy enough to make available, for anyone who really wants it.
I think I'll sleep on it and make a decision one way or the other afterwards.
On 29/09/2008 at 08:22, xxxxxxxx wrote:
Ok, I came up with a solution...
- I replaced the obsolete tags' icons with a distinctive one
- if the user double-clicks it (to edit it, old school), a MessageDialog() opens, telling them that the tag is obsolete and to fix it (them), hold the <SHIFT> key an do an ".Obj Export" (which is an existing Command plugin)...
-...which will fix the tags, instead of exporting, if the SHIFT key is down.
Tested, working, done :).
I also now have Riptide Pro looking to see if those tag plugins are already installed and not install it's own if they are... I just need to do a similar change to the free Riptide, unless I can figure out the plugin load Priority thing so that the Pro version would load after the free one.
On 29/09/2008 at 08:27, xxxxxxxx wrote:
On 29/09/2008 at 08:47, xxxxxxxx wrote:
Excellent - thanks!
Just one remaining issue... I want the tag icons to show up on the objects in the OM, but I don't want the pop-up menu entries to add one of those tags.
I'm currently doing:
...which should make the tag itself (?) visible, but hide the menu entry... it's not hiding the menu entry.
On 29/09/2008 at 08:50, xxxxxxxx wrote:
..nevermind. It looks like I need
**PLUGINFLAG_HIDE** instead of **PLUGINFLAG_HIDEPLUGINMENU**.. who'd-a-thunk-it?
On 29/09/2008 at 08:56, xxxxxxxx wrote:
Yeah that same thing confused me, too. ;o)
It seems that PLUGINFLAG_HIDEPLUGINMENU is there for commands, because if you use PLUGINFLAG_HIDE for a command, the command won't perform its function. :o(
But for objects and tags PLUGINFLAG_HIDE works.
On 29/09/2008 at 09:04, xxxxxxxx wrote:
Interesting. There are some cases where the one-liner 'docs' aren't sufficient, I guess :).