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

FreeCAD: occt7.1.0 and windows (RTTI-DATA missing)

Lorenz Lechner's picture

We (FreeCAD) are facing some problems with occt7.1.0 on windows. While this version works on linux and mac, windows has some problems with Handles.

Converting argument 2 of "opencascade::handle<TColgp_HArray1OfPnt>" in "Handle_TColgp_HArray1OfPnt &" not possible

It was possible to overcome this problem by using  Handle(TColgp_HArray1OfPnt) instead of  Handle_TColgp_HArray1OfPnt. But we also facing some run-time warnings:

access violation - no RTTI data!

There is no such problem with occt7.0.0
Maybe you have some ideas, what changes between 7.0.0 and 7.1.0 could be related to this problem.

nice regards

Kirill's picture

Converting argument 2 of "opencascade::handle<TColgp_HArray1OfPnt>" in "Handle_TColgp_HArray1OfPnt &" not possible

- Within older versions of OCCT, Handle() was macros converting name to Handle(Class) -> Handle_Class, where Handle_Class were actual classes generated by WOK or other macros.
- Within OCCT 7.0.0, where WOK has been abandoned and more standard C++ mechanisms have been used for defining OCCT smart pointers,
Handle() now directs to opencascade::handle<Class> template class, while Handle_ classes are defined by DEFINE_STANDARD_HANDLECLASS() as typedef for *compatibility with old code*.
- Within OCCT 7.1.0 DEFINE_STANDARD_HANDLECLASS defining Handle_ has been corrected so that it defines real class inheriting from Handle(),
which is useful within some contexts (e.g. making public is not possible for template classes within C++/CLI) - but this change applies only for Visual Studio compiler (see source code of the macros).

Since Handle() and Handle_ are not the same thing on msvc anymore - it might result in such kind of errors.
The solution is simple - use Handle() where possible instead of obsolete Handle_ (Handle() has been always recommended way for declaring classes - Handle_ is rather internal).
It might be useful looking through the code to clean up all redundant occurrences of Handle_.

Lorenz Lechner's picture

thanks for the information. This is exactly what we needed.