Hide Tags
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 04/03/2006 at 09:12, xxxxxxxx wrote:
User Information:
Cinema 4D Version: 7.3+
Platform: Windows ;
Language(s) : C++ ;---------
Hi,
I see that I have the option to create plugin tags that are 'visible' or not... is there some way to programatically 'hide' tags that already exist? Even if I had to clone the object and copy the tags over, that would be ok, but I don't see a way to force them to be hidden.
I'm interested in all tag types, but particularly in things like Selection tags.
Thanks. -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 04/03/2006 at 11:39, xxxxxxxx wrote:
Not possible. (in the famous words of Mikael)
For plugin tags, since this is a 'state' that is set on 'Register...', it can only be changed when registering the plugin. If you can find a way to decide on startup of Cinema 4D, you can hide or show your own tags.
But there is nothing to be done for the built-in tags.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 04/03/2006 at 12:12, xxxxxxxx wrote:
In the famous words of Homer - "D'oh!"
I was afraid of that. I can implement my own selection tags, but they wouldn't get updated by other tools like the C4D ones do.
Thanks. -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 05/03/2006 at 09:49, xxxxxxxx wrote:
From R9 onwards all tags update themselves when modeling happens, see MSG_TRANSLATE_POINTS. Any tag is sent a message during modeling that informs it what is changing and how to update its data. If you need any example code I can post some.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 05/03/2006 at 14:40, xxxxxxxx wrote:
I guess that won't help me in the R8 case, but I'll look into that for R9.
Thanks. -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 06/03/2006 at 02:06, xxxxxxxx wrote:
New, but related question...
Ok, I have a PluginTag, which is storing SelectionTags in it's BaseContainer...
The SelectionTags are NOT attached to any Object, so I'm storing them in the BaseContainer with:
plugin_bc->SetLink(SELTAG_LINK, (BaseList2D * )pSelTag); // add new tag to plugin container
...and I'm retrieving them from the container as follows:
BaseLink *pLink;
pLink = plugin_bc->GetBaseLink(SELTAG_LINK);
pSelTag = (SelectionTag * )pLink->ForceGetLink();...so far, this seems to be working, until I save/load a file that has one of these PluginTags in it - and then retrieving the tag (pLink->ForceGetLink()) results in a NULL.
So my question is, it seems to me that the SelectionTags (stored in my BaseContainer using SetLink()) are either not being saved to disk correectly, or not read from disk correctly. Is this because they are not attached to any Object (and therefore, also not attached to any Document)?
Any help on fixing this would be appreciated.
Thanks. -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 06/03/2006 at 02:48, xxxxxxxx wrote:
If they are not attached to an object they can not be saved with the document. Setting a pointer in the link is not going to cause the tag to be saved. Why do you need to use a selection tag? Can't you just use a BaseSelect, you just need to add the CopyTo, Read and Write. The BaseSelect has functions for these.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 06/03/2006 at 02:59, xxxxxxxx wrote:
I could use a BaseSelect.. but how do I add a Baselect to my plugin BaseContainer?
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 06/03/2006 at 03:03, xxxxxxxx wrote:
...Wouldn't that require a CustomDataType and bc->SetData()?
...or, are you suggesting that I store the BaseSelect pointer(s) as members of my class and implement the Read()/Copy()/Write() methods in there?
I was assuming that the Read()/Copy()/Write() of the root Atom class of the SelectionTag would handle the disk stuff, but I guess the problem is that these tags are not attached to the document (they're not atached, so they don't get displayed - which is the point of the plugin).
I could switch over to just tracking the BaseSelect of the tags, with some additional work... I guess I have to implement the Read()/Copy()/Write() stuff either way - unless there's some way of storing the BaseSelect pointers in my plugin's BaseContainer... right?
Thanks. -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 06/03/2006 at 03:23, xxxxxxxx wrote:
...I just realized the other reason I'm using SelectionTags instead of BaseSelects... BaseSelects don't have names attached, which is needed for this plugin.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 06/03/2006 at 04:26, xxxxxxxx wrote:
Without knowing what you are trying to achieve its hard to advise. Trying to use a SelectionTag not stored in a document could be messy. Add the baseselect to your class and store the selection in it, implementing the Read/Write/Copy is simple since BaseSelect has the functions for these itself. If you need a name, store this too. If you can give a little more info it might be easier to know what to advise.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 06/03/2006 at 04:45, xxxxxxxx wrote:
Thanks, I think that's enough for me to go on for now - I was just hoping to avoid having to implement the Read/Write/Copy, since I hadn't messed with that before, but I'll look through the docs and sample code and give that a shot.
The basic idea is to track some Selection Tags without having them all (could be 100 of them) strung out attached to my object. It sounds like I can't 'hide' them, so they are not attached to the object/document. Since they're not attached, it sounds like they won't get auto-saved/read for me. Which means using the BaseContainer to store them is not of much use to me in this case (and a bit clumsy to start with, since it's a variable number of them).
Since it looks like I'll need to implement the R/W/C stuff anyway, that pretty much opens up other options for handling them.
Thanks again. -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 06/03/2006 at 10:17, xxxxxxxx wrote:
Notes:
- polyArray is a private class member to IPPFigure.
- IPPFIGURE_POLYCOUNT is a LONG resource storing the number of polyArray elements.// NodeData.Init //*---------------------------------------------------------------------------* Bool IPPFigure::Init(GeListNode* node) //*---------------------------------------------------------------------------* { polyArray = NULL; return TRUE; } // NodeData.Free //*---------------------------------------------------------------------------* void IPPFigure::Free(GeListNode* node) //*---------------------------------------------------------------------------* { GeFree(polyArray); } // NodeData.Read: Read data from HyperFile //*---------------------------------------------------------------------------* Bool IPPFigure::Read(GeListNode* node, HyperFile* hf, LONG level) //*---------------------------------------------------------------------------* { if (level >= 0) { BaseContainer* bc = ((BaseTag* )node)->GetDataInstance(); LONG size = sizeof(CPolygon)*bc->GetLong(IPPFIGURE_POLYCOUNT); polyArray = (CPolygon* )GeAlloc(size); if (!polyArray) return ErrorException::Throw(GeLoadString(ERROR_MEMORY_TEXT), "IPPFigure.Read.polyArray"); hf->ReadMemory((void** )&polyArray;, &size;); } return TRUE; } // NodeData.Write: Write data to HyperFile //*---------------------------------------------------------------------------* Bool IPPFigure::Write(GeListNode* node, HyperFile* hf) //*---------------------------------------------------------------------------* { // Level 0 if (polyArray) hf->WriteMemory(polyArray, sizeof(CPolygon)*((BaseTag* )node)->GetDataInstance()->GetLong(IPPFIGURE_POLYCOUNT)); // Level 1 return TRUE; } // NodeData.CopyTo: Copy data to copied PluginTag //*---------------------------------------------------------------------------* Bool IPPFigure::CopyTo(NodeData* dest, GeListNode* snode, GeListNode* dnode, LONG flags, AliasTrans* trn) //*---------------------------------------------------------------------------* { if (polyArray) { BaseContainer* bc = ((BaseTag* )snode)->GetDataInstance(); IPPFigure* fdest = (IPPFigure* )dest; LONG size = sizeof(CPolygon)*bc->GetLong(IPPFIGURE_POLYCOUNT); fdest->polyArray = (CPolygon* )GeAlloc(size); if (!fdest->polyArray) return ErrorException::Throw(GeLoadString(ERROR_MEMORY_TEXT), "IPPFigure.CopyTo.adest->polyArray"); CopyMem(polyArray, fdest->polyArray, size); } return TRUE; }That'll get you started.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 06/03/2006 at 10:40, xxxxxxxx wrote:
Hey Robert,
Thanks... you know, I didn't think to look in your code yet This is Keith, BTW.
Anyway, I got the basic framework code working under my new approach last night... now I'm of to do the R/W/C code, so this will come in handy. -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 06/03/2006 at 10:45, xxxxxxxx wrote:
Hi Keith,
This is widdled down code so that you can see what the bare necessities are (you'll see that a couple other things are being done in the code that would confuse things a little). Also good if anyone else needs help in implementing these methods.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 06/03/2006 at 11:14, xxxxxxxx wrote:
Yep - thanks. Will be testing again in a few minutes :).
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 06/03/2006 at 15:48, xxxxxxxx wrote:
Ok, everything is now working as expected... now I need to look into keeping the selections up to date...
David (or anyone who knows), can you tell me the functional difference between MSG_POINTS_CHANGED (which is available in R8) and MSG_TRANSLATE_POINTS (which only starts happening in R9) ?
Could I look for MSG_POINTS_CHANGED in both R8 and R9 and use that?
Thanks. -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 07/03/2006 at 01:18, xxxxxxxx wrote:
MSG_POINTS_CHANGED will help a little, see VariableChanged in the sdk docs. The difference is that MSG_TRANSLATE_POINTS (and a number of other _TRANSLATE_ and _PRETRANSLATE_) give you more information about what its happening, like the points getting welded or cloned or deleted or moved etc. MSG_POINTS_CHANGED just gives a mapping table of the old to new points.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 07/03/2006 at 02:03, xxxxxxxx wrote:
Yeah, in this first case, I'm looking at Polygons, so... I'm trying to invision what the VariableChanged data is/can tell me - and whether or not that's usefull...
- There may be more polygons than there used to be:
...Probably doesn't affect my selection tags much, except where the mapping/ordering may be different.
- There may be fewer polygons than there used to be:
...so some polys in my selection tags may no longer exist (along with a potential re-ordering).
- The ordering may have changed for some reason or another.
...so the selection tags will need to get updated to match the new ordering.
As you mention, what it doesn't tell me is a lot of potentially usefull information about 'how' things are changing... for example, if a polygon/quad (that exists in one of my tags) gets 'split' into two triangles (for example), ideally, the two triangles would be part of that list in place of the one quad. The VariableChanged structure doesn't give me enough information to determine if this is te case or not.
I guess the worst-case scenerio is similar to that... my selections won't include logical changes when cutting the mesh up (as well as an issue related to expanding selections when collapsing Symmetry objects...).
Some of the other issues you mention (welding, cloning, etc) will have more meaning on the Point selections... hmmm, I guess I can start with the R8- compatible case and look at the _TRANSLATE_ messages for R9 after I get that working.
Thanks.
BTW, As a Plugin Tag, is there any way for me to know when someone is calling "doc->Polygonize()" ? Is there any way for any type of plugin to know about that? -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 07/03/2006 at 02:08, xxxxxxxx wrote:
David, if you're interested/curious, send me an e-mail and I'll send you the plugin to see what I'm doing. typhoon[at]charter[dot]net