Class TSFNode

Construct a field allowing any children class. Suitable only for special cases. For example, in instantiated prototypes, we must initially just allow all children, otherwise valid prototypes with SFNode/MFNode would cause warnings when parsing.

Constructor that takes a list of allowed children classes. Note that we copy the contents of AAllowedChildrenClasses, not the reference.

Constructor that allows as children any implementor of given functionality.

Checks is the Child allowed as a value of this SFNode, and makes WritelnWarning if not.

Check is allowed is done looking at AllowedChildrenAll and AllowedChildren properties.

Child must not be Nil.

WritelnWarning message will suggest that this Child is used as value of this node. In other words, you should only pass as Child a node that you want to assign as Value to this field, otherwise WritelnWarning message will be a little unsensible.

Calls Func for our Value, assuming it's set (non-nil). The main use for this is to simplify implementation of TX3DNode.DirectEnumerateActive overrides in TX3DNode descendants.

Default value of SFNode field.

While X3D specification says for all SFNode fields that their default value is NULL, this is not necessarily true for PROTO SFNode fiels. So we have to take into account that any DefaultValue is possible.

Note that this doesn't have to be Nil, but will be irrelevant if not DefaultValueExists. (Once I had an idea to automatically set DefaultValue to Nil when DefaultValueExists is set to False, but this was uncomfortable (like "what to do when DefaultValue is assigned non-nil when DefaultValueExists is false?").)

Freeing of this is automatically managed, just like the normal Value property. This means that you can simply set DefaultValue to Nil or some existing node, and eventual memory deallocation of previous DefaultValue node (if unused) will happen automatically.

VRML node containing this field. May be Nil if unknown, in special cases.

Note that this property is exactly the same as TX3DFieldOrEvent.ParentNode, contains always the same value. But this is declared as TX3DNode, so it's more comfortable.

Use weak links to deal with cycles in the X3D graph.

Marking a field as a weak link can only be done when the field value is empty, right when the field is created, in TX3DNode.CreateNode descendant.

Being a weak link means two things:

1. The nodes inside a weak link are not enumerated when traversing the X3D graph in any way. This includes TX3DNode.EnumerateNodes, TX3DNode.Traverse and all others. Nodes implementing TX3DNode.DirectEnumerateActive should also omit these fields.

2. A weak link does not create a reference count preventing the node from being freed (or freeing it automatically when ref count drops to zero). Instead, weak links merely observe the nodes, and automatically set their value to Nil when the node gets freed.

If effect, this avoids loops when enumerating (and avoids recursive loops in reference counts, which would cause memory leaks), but use this only when you know that the node must occur somewhere else in the X3D graph anyway (or it's OK to ignore it). For example, this is useful for TGeneratedShadowMapNode.Light, as we know that the light must occur somewhere else in the graph anyway to be useful.

Automatically use WeakLink if field would contain a node cycle. Using WeakLink=true allows to handle node cycles, like common in VRML/X3D

DEF Xxx Transform {
  children [
    ...
    Script {
      ...
      inputOutput SFNode someField USE Xxx
    }
  ]
}

When AutomaticWeakLink, the given field contents may, but don't have to, be a node cycle – we only use WeakLink when necessary.

Use this only for fields that are not enumerated by DirectEnumerateActive, Traverse etc., otherwise you create a cycle in nodes that we generally cannot handle.