DescriptionCheckUpdate.descid = crash!

Helper

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

On 04/03/2006 at 22:18, xxxxxxxx wrote:

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

---------
No matter what I do, there seems no sane way to reference the DescLevel of the DescID in a DescriptionCheckUpdate structure (no examples either). Since it is a pointer, the [] operator will not compile on dcu->descid[0].id. So I figure it needs to be dereferenced. But all my varied attempts so far equal compiler error or a Cinema 4D crash - specific to the marked lines:

     // React on Figure object dropped into IPPFIGURE_CONFORMTO  
     else if (MSG_DESCRIPTION_CHECKUPDATE)  
     {  
          DescriptionCheckUpdate*     dcu =          static_cast<DescriptionCheckUpdate*>(data);  
// +CRASH  
          DescID descID =                              *(dcu->descid);  
          if (descID[0].id == IPPFIGURE_CONFORMTO)  
// -CRASH  
          {  
               BaseDocument*               baseDoc =     node->GetDocument();  
               if (!baseDoc)                              return FALSE;  
               BaseContainer*               bc =          ((BaseTag* )node)->GetDataInstance();  
               if (!bc)                                   return FALSE;  
               if (!node->GetDescription(desc,0))     return FALSE;  
               BaseObject*     obj =          bc->GetObjectLink(IPPFIGURE_CONFORMTO, baseDoc);  
               if (obj)                    GePrint("Conform To: "+obj->GetName());  
          }  
     }

I've tried (*(dcu->descid))[0] (no compile) and ((DescID)*(dcu->descid))[0] (crash) among others. Is there any way to get this dereferenced in order to apply the DescLevel operator!? It is the ONLY way to get at the DescLevel...

Thanks,

Helper

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

On 04/03/2006 at 23:36, xxxxxxxx wrote:

Ah, nevermind. I see that a similar dereference in the API code is commented out (wonders why...). I'll just use a darned BUTTON resource.