Unwanted clearing of TagData member variables

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 06/08/2010 at 19:52, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   11.5
Platform:   Windows ;
Language(s) :     C++ ;

---------
Values stored in private member variables are being cleared between calls to TagData::Execute() when extruding by dragging in the viewport.

I'm testing using this code:

  
LONG SymmetryClamp::Execute(PluginTag *tag, BaseDocument *doc, BaseObject *op, BaseThread *bt, LONG priority, LONG flags)   
{   
     PolygonObject *polyObj = ToPoly(op);   
     if(!polyObj) return FALSE;   
  
     GePrint("prevCnt_1: " + LongToString(prevCnt));   
  
     prevCnt = polyObj->GetPointCount();   
  
     GePrint("prevCnt_2: " + LongToString(prevCnt));   
  
     return EXECUTION_RESULT_OK;   
}

Applying the Extrude tool (Subdivision 0) to a quad on an object with 34 points gives the following results:

Console output for first call
prevCnt_1: 34
prevCnt_2: 38

Subsequent calls
prevCnt_1: 0
prevCnt_2: 38

Last call upon mouse release
prevCnt_1: 38
prevCnt_1: 38

Values are retained when e.g. dragging points or using the knife tool.

Is there a solution to this problem?

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 12/08/2010 at 06:16, xxxxxxxx wrote:

Can I please have a response from support on this issue?

Resolving it is the last step in completing the plugin, which is otherwise working as intended.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 12/08/2010 at 09:41, xxxxxxxx wrote:

Sorry for the late reply, I am currently reallt busy with lots of other things.

As for your problem, it seems Extrude is creating copies of the object during extruding. What you can do is to initialize the member variable with the current point number. Overload Init() to do so.

Example:

  
Bool SymmetryClamp::Init(GeListNode *node)  
{  
  BaseTag    *tag  = (BaseTag* )node;  
  BaseObject *op = tag->GetObject();  
  
  if (op && op->GetType() == Opolygon)  
      prevCnt = ToPoly(op)->GetPointCount();  
  else  
      prevCnt = 0;  
  
  return TRUE;  
}

Or alternatively you can use a global variable.

cheers,
Matthias

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 12/08/2010 at 10:15, xxxxxxxx wrote:

Also, if you have private member variables that should be preserved when your TagData is copied or cloned (and that happens A LOT), you should override at least the CopyTo() function from the parent class.

Cheers,
Jack

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 12/08/2010 at 23:07, xxxxxxxx wrote:

No worries, thanks for the reply Matthias. I have a clearer idea of what's happening now.

As well as a point count, I need to store an array of indices in a member variable and refresh it if the point count changes between calls. Global and static local variables retain their values when extruding but are not suitable for multiple instances.

Using the above example, overloading Init() results in prevCnt remaining at 34 between calls although the count has increased to 38. A point count difference would therefore be incorrectly detected. Also, when using other tools the test for op fails and prevCnt is set to 0.

The tag's container works for the point count but this is of course unsuitable for an array.

I tried investigating filling the array in Message() but when op is under a generator, a point count difference is found despite the number of points in op being unchanged. MSG_POINTS_CHANGED appears to be sent whenever a generator cache is rebuilt. The point count returned in Message() corresponds with the rebuilt cache. An archive search returned this message but it doesn't help as no duplicate references are present in the tag list.

Thanks also Jack for the suggestion. In this case I don't need to preserve member variables when copying and cloning but I'll keep it in mind for future use.