|
|
|
|
- It is impossible to manage real inputs orientation in Meta Inputs
instantiation mode. If allowed in the template definition, you can switch
to a standard instantiation mode, select the input to edit and then
change the orientation.
|
- For User Features created in R17: It is possible to drive the color of the User Feature instance from
one of its published parameters. If all internal components of the User
Feature are colorized, it is no more possible to apply a color on the
User Feature instance.
It is highly recommended not to use Knowledge parameters in User Features
to drive their graphic properties.
|
- References UDFs do not contain specifications. They are not
considered as geometrical features and thus do not have any geometrical
result. That's why they appear as "not updated" in the specification tree
and in the Edit/Properties window.
|
- User Feature graphical properties (such as color, show/hide
status, ...) depend on the graphical properties of the User Feature components at
creation. As soon as the User Feature is created, i.e. as soon as the
components are defined and validated (either by clicking OK
in the definition window or by changing tabs), the graphical
properties of the User Feature are "frozen" and thus independent from
the graphical properties of its components.
The reason why the User Feature graphical properties are independent
from its internal graphical properties is that the User Feature is a
feature with its own graphical properties. Those properties can be
modified using the Properties contextual command. If the User Feature
properties were dependant from the User Feature internal components,
you would not be able to modify the User Feature graphical properties
using the Properties contextual command, or the graphical properties
available from the contextual command and graphical properties
defined by parameter would not match.
So it is highly recommended not to use Knowledge parameters inside
the User Feature to drive its graphical properties.
|
- User Features do not support standards used in the definition of
thread features.
|
- Since a UDF is considered as a black box, its results cannot expose
its contents. It does not specifically implement applicative interfaces
i.e. it does not implement axis systems interfaces and cannot be
considered as an axis system by the commands that take an axis system in
input.
|
- User Feature needs the geometry of internal components to be built.
Since geometry of deactivated elements is not available, User Features
should not be created using deactivated elements as it is invalid input.
|
