For all issues regarding the Forums use, please, refer to the Forum Rules.

Our Solutions

Need professional assistance?
Consider our:

Support Offerings


Need to speed up your development?
Have a look at our:

Samples & Tools


Need some functionality extending standard OCCT capabilities?
Check out our:

Adv. Components

Related pages

Handle(TDataStd_Name) has a wrong ID() in OCCT 7.2.0

walter steffe's picture

The condition at line 10 of the annexed c++ code: 

10:    if(nameAtt->ID().IsSame(TDataStd_Name::GetID()))

evaluates to true if the code is built with  OCC 6.9.1

while it  evaluates to false if the code is built with  OCC 7.2.0

The second result is wrong and because of that the following function (which is defined in TDF/TDF_Label.cxx):

void TDF_Label::AddAttribute (const Handle(TDF_Attribute)& anAttribute,
                              const Standard_Boolean append/* = Standard_False*/)  const

does not work in OCCT 7.2.0 when a Handle(TDataStd_Name) is passed to the first argument


Benjamin Bihler's picture

I have the same behaviour here. Isn't the problem that the empty constructor of TDataStd_Name doesn't initialize the member fields correctly?

Mikhail MPV's picture

Since OCCT 7.1.0 same type attributes may have different GUIDs. Because of this the attribute constructor does not initialize GUID. See a chapter "Support of several attributes of one type at the same label" in Release Notes.

So, before AddAttribute you should call


Anyway, the standard way to create and attach attribute to a label is to use "Set" method of the attribute. It works well on any version of OCCT.

I registered an issue 29371 in the bugtracker to avoid such a problem later.

walter steffe's picture

Hello Benjamin, thanks for your hint.

I think you are right. The problem arises because TDataStd_Name::myID is not initialized inside of the empty constructor.

However I have seen that it can be fixed by adding a call to TDataStd_Name::setID() just after the constructor:

  Handle(TDataStd_Name) nameAtt=new TDataStd_Name();


Perhaps it would have been better if the call had been included in the constructor without breaking the compatibility with OCCT 6.9.1.

But it just is a matter of choice and not really a bug.