tag->Remove() within 'tag' code - how?
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
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. -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 28/09/2008 at 20:29, xxxxxxxx wrote:
Howdy,
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?
Adios,
Cactus Dan -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
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.
Keith -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
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.
cheers,
Matthias -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
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.
Thanks. -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
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. -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 29/09/2008 at 08:27, xxxxxxxx wrote:
Howdy,
case C4DMSG_PRIORITY:
SetPluginPriority(data, C4DPL_INIT_PRIORITY_PLUGINS-1);
return TRUE;Adios,
Cactus Dan -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
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:return RegisterTagPlugin(GTAG_PLUGID,name,TAG_VISIBLE|PLUGINFLAG_HIDEPLUGINMENU,FixGroupTag::Alloc,"","obsolete.tif",0);...which should make the tag itself (?) visible, but hide the menu entry... it's not hiding the menu entry.
Any thoughts? -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
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? -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 29/09/2008 at 08:56, xxxxxxxx wrote:
Howdy,
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.
Adios,
Cactus Dan -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 29/09/2008 at 09:04, xxxxxxxx wrote:
Interesting. There are some cases where the one-liner 'docs' aren't sufficient, I guess :).