Class TX3DField

Normal constructor.

Descendants implementors notes: when implementing constructors in descendants, remember that Create in this class actually just calls CreateUndefined, and CreateUndefined is virtual. So when calling inherited Create, be aware that actually you may be calling your own overriden CreateUndefined.

In fact, in descendants you should focus on moving all the work to CreateUndefined constructor. The Create constructor should be just a comfortable extension of CreateUndefined, that does the same and addiionally gets parameters that specify default field value.

Virtual constructor, that you can use to construct field instance when field class is known only at runtime.

The idea is that in some cases, you need to create fields using variable like FieldClass: TX3DFieldClass. See e.g. TX3DInterfaceDeclaration, VRML 2.0 feature that simply requires this ability, also implementation of TX3DSimpleMultField.Parse and TX3DSimpleMultField.CreateItemBeforeParse.

Later you can initialize such instance from string using it's Parse method.

Note that some exceptional fields simply cannot work when initialized by this constructor: these are SFEnum and SFBitMask fields. They simply need to know their TSFEnum.EnumNames, or TSFBitMask.FlagNames + TSFBitMask.NoneString + TSFBitMask.AllString before they can be parsed. I guess that's one of the reasons why these field types were entirely removed from VRML 2.0.

Parse inits properties from Lexer.

In this class, Parse only appends to IsClauseNames: if we stand on "IS" clause (see VRML 2.0 spec about "IS" clause) and IsClauseAllowed then we append specified identifier to IsClauseNames.

If "IS" clause not found, we call ParseValue which should actually parse field's value. Descendants should override ParseValue.

Parse field value from X3D XML encoded attribute using a Lexer. Attributes in X3D are generally encoded such that normal ParseValue(Lexer, nil) call is appropriate, so this is done in this class.

Parse field value from X3D XML encoded attribute.

Implementation in this class creates a Lexer to parse the string, and calls ParseXMLAttributeLexer.

Parse field's value from XML Element children. This is used to read SFNode / MFNode field value inside <field> (for interface declaration default field value) and <fieldValue> inside <ProtoInstance>.

Save the field to the stream. Field name (if set, omitted if empty) and value are saved. Unless the current field value equals default value and FieldSaveWhenDefault is False (default), then nothing is saved.

IS clauses are not saved here (because they often have to be treated specially anyway, for XML encoding, for prototype declarations etc.).

Save the field to the stream.

This simply calls FieldSaveToStream(Writer). See FieldSaveToStream for more comments and when you need control over FieldSaveWhenDefault behavior.

It doesn't actually save anything if field value is defined and equals default value.

Whether the value is equal to default. Returns always False in TX3DField, descendants should override it. It is used when writing the field value to X3D file (values that are default do not have to be written, ever).

True if the SecondValue object has exactly the same type and properties. For this class, this returns just (SecondValue.Name = Name).

All descendants (that add some property that should be compared) should override this like

Result := (inherited Equals(SecondValue)) and
  (SecondValue is TMyType) and
  (TMyType(SecondValue).MyProperty = MyProperty);

The floating-point fields may be compared with a small epsilon tolerance by this method.

Note that this *doesn't* compare the default values of two fields instances. This compares only the current values of two fields instances, and eventually some other properties that affect parsing (like names for TSFEnum and TSFBitMask) or allowed future values (like TSFFloat.MustBeNonnegative).

Compare value of this field, with other field, fast.

This compares only the values of the fields, not other properties (it doesn't care about names of the fields or such, or default values; only current values). In other words, it compares only the things copied by AssignValue.

This tries to compare very fast, which means that for large (multi-valued) fields it may give up and answer False even when they are in fact equal. So this is usable only for optimization purposes: when it answers True, it is True. When it answers False, it actually doesn't know.

Default implementation in this class (TX3DField) just returns False.

Exposed events of this field. Nil if this field is not exposed. EventIn is always equivalent to ExposedEvents[true], EventOut is always equivalent to ExposedEvents[false].

Field type in X3D, like 'SFString' or 'MFInt32'. As for VRML/X3D interface declaration statements. In base TX3DField class, this returns XFAny (name indicating any type, used by instantreality and us).

Warning: this symbol is deprecated: use X3DType

Create TX3DEvent descendant suitable as exposed event for this field.

Copies the current field value. Contrary to TPersistent.Assign, this doesn't copy the rest of properties.

After setting, our ValueFromIsClause is always changed to False. You can manually change it to True, if this copy indeed was done following "IS" clause.

Descendants implementors notes:

In this class, implementation takes care of setting our ValueFromIsClause to False. In descendants, you should do like

if Source is <appropriate class> then
begin
  inherited;
  Value := Source.value;
end else
  AssignValueRaiseInvalidClass(Source);

Exceptions raised

EX3DFieldAssignInvalidClass

Usually it's required the Source class to be equal to our class, if Source classes cannot be assigned we raise EX3DFieldCannotAssignClass.

EX3DFieldAssign

Raised in case of any field assignment problem. It's guaranteed that in case of such problem, our value will not be modified before raising the exception.

EX3DFieldAssignInvalidClass inherits from EX3DFieldAssign, so actually EX3DFieldAssignInvalidClass is just a special case of this exceptiion.

Set field's default value from the current value.

Note that for now this doesn't guarantee that every possible field's value can be stored as default value. In case of trouble, it will silently record "no default is known" information, so e.g. EqualsDefaultValue will always return False. Our default value mechanisms are sometimes limited, not every value can be a default value. For example, for multiple-valued nodes, we usually cannot save arrays longer than one as default value. This is not a problem, since X3D specification doesn't specify too long default values. But it may be a problem for prototypes, since then user can assign any value as default value. May be corrected in the future.

Remove default value, recording that "no default is known". In effect EqualsDefaultValue will always return False.

Assigns value to this node calculated from linear interpolation between two given nodes Value1, Value2. Just like other lerp functions in our units (like CastleVectors.Lerp).

Like AssignValue, this copies only the current value. All other properties (like Name, IsClauseNames, ValueFromIsClause, default value) are untouched.

There are some special precautions for this:

• First of all, AssignLerp is defined only for fields where CanAssignLerp returns True, so always check CanAssignLerp first. All float-based fields should have this implemented.

• Use this only if Value1 and Value2 are equal or descendant of target (Self) class.

• For multiple-value fields, counts of Value1 and Value2 must be equal, or EListsDifferentCount will be raised.

Exceptions raised

EListsDifferentCount

When field is multiple-value field and Value1.Count <> Value2.Count.

Is AssignLerp usable on this field type?

Descendants implementors notes: In this class, this always returns False.

Notify ParentNode.Scene that the value of this field changed.

What happens when the value of this field changes. This is called, exactly once, by TCastleSceneCore.InternalChangedField to determine what must be done when we know that value of this field changed.

In overridden descendants, this can also do something immediately. Overriding this is similar to registering your callback by EventOut.AddNotification, with two additional benefits:

1. This method may be not called (although no guarantees) when the actual field value did not change. In contrast, the event notification is always fired, even when you send the same value to an exposed field, because VRML/X3D events and routes must be fired anyway.

2. This is useful also for fields that are not exposed, and can be changed only by ObjectPascal code.

So overridding this is closer to "do something when field value changes" than registering notification by EventOut.AddNotification.

Set the value of the field, notifying the scenes and events engine. This sets the value of this field in the nicest possible way for any possible TCastleSceneCore (with events on or off) containing the node with this field.

Precise specification:

• If this is an exposed field and we have events engine working:

  We will send this value through it's input event. In this case, this is equivalent to doing EventIn.Send(Value, Scene.Time). The scenes (including events engine) will be notified correctly by exposed events handler already.

• Otherwise, we will just set the fields value. And then notify the scenes (including events engine).

Notifications when exposed field received new value through VRML/X3D event. Use only for exposed fields. This is simply a shortcut for EventOut.AddNotification, EventOut.RemoveNotification, see TX3DEvent.AddNotification for details how does this work.

Note that this observes the "out" event (not the "in" event). This way you know inside the handler that the field value is already changed as appropriate. Inside "in" event handlers, you would not know this (it would depend on the order in which handlers are run, one "in" handler sets the field value).

Note that "out" event handlers are executed before Scene is notified about the field value change (before TCastleSceneCore.InternalChangedField is called). This is also usually exactly what you want — you can change the scene graph inside the event handler (for example, load something on Inline.load or Inline.url changes), and let the TX3DField.ChangeAlways cause appropriate action on this change.

Does current field value came from expanding "IS" clause. If yes, then saving this field to stream will only save it's "IS" clauses, never saving actual value.

Does this field generate/accept events, that is an "exposedField" (in VRML 2.0) or "inputOutput" (in X3D).

These are the set_xxx and xxx_changed events exposed by this field. Nil if Exposed is False.

When True (default) we will automatically handle exposed events behavior. This means that we will listen on EventIn, and when something will be received we will set current field's value and produce appropriate EventOut.

You almost certainly want to leave this as True in all typical situations, as it takes care of implementing required exposed events behavior.

That said, in special cases you may decide to break this.

What always happens when the value of this field changes.

This is included in the ExecuteChange method result. So instead of using this property, you could always override ExecuteChange method. But often it's easier to use the property.

By default this is chNone. See TX3DChange for possible values.