Class TMFVec4fEvent

This item has no description.

Source: scene/x3d/castlefields_x3dfileitem.inc (line 42).

Save to stream.

Source: scene/x3d/castlefields_x3dfileitem.inc (line 75).

How is this saved to X3D XML encoding. This determines when SaveToStream is called. It also cooperates with some SaveToStream implementations, guiding how the item is actually saved. By default it is sxChildElement.

Source: scene/x3d/castlefields_x3dfileitem.inc (line 81).

This item has no description.

Source: scene/x3d/castlefields_x3dfieldorevent.inc (line 47).

This item has no description.

Source: scene/x3d/castlefields_x3dfieldorevent.inc (line 48).

This item has no description.

Source: scene/x3d/castlefields_x3dfieldorevent.inc (line 102).

This item has no description.

Source: scene/x3d/castlefields_x3dfieldorevent.inc (line 103).

This item has no description.

Source: scene/x3d/castlefields_x3dfieldorevent.inc (line 104).

Parse only "IS" clause, if it's not present — don't do nothing. For example, for the TX3DField descendant, this does not try to parse field value.

Source: scene/x3d/castlefields_x3dfieldorevent.inc (line 110).

Add alternative name for the same field/event, to be used in different VRML version.

When VRML major version is exactly equal X3DMajorVersion, the AlternativeName should be used — for both reading and writing of this field/event. In some cases, when reading, we may also allow all versions (both original and alternative), but this is mostly for implementation simplicity — don't count on it.

A special value 0 for X3DMajorVersion means that this is just an alternative name, that should be allowed when reading (as alternative to normal Name), and never used when writing.

Alternative names is a very handy mechanism for cases when the only thing that changed between VRML versions is the field name. Example: Switch node's children/choice, LOD node's children/level, Polyline2D lineSegments/point.

Note that this also works for ExposedEvents with exposed TX3DField: if a field has alternative names, then it's exposed events always also have appropriate alternative names.

Source: scene/x3d/castlefields_x3dfieldorevent.inc (line 133).

This item has no description.

Source: scene/x3d/castlefields_x3dfieldorevent.inc (line 135).

Returns if S matches current Name or one of the alternative names. Think about it like simple test "Name = S", but actually this checks also names added by AddAlternativeName method.

Source: scene/x3d/castlefields_x3dfieldorevent.inc (line 140).

Return how this field should be named for given VRML version. In almost all cases, this simply returns current Name. But it can also return a name added by AddAlternativeName method.

Source: scene/x3d/castlefields_x3dfieldorevent.inc (line 145).

This item has no description.

Source: scene/x3d/castlefields_x3dfieldorevent.inc (line 146).

Nice and concise field description for user. Describes parent node type, name and field/event's name.

Source: scene/x3d/castlefields_x3dfieldorevent.inc (line 159).

Save IS clauses to stream, only for classic encoding. For each IS clause, writeln field/event name followed by "IS" clause.

Source: scene/x3d/castlefields_x3dfieldorevent.inc (line 163).

This item has no description.

Source: scene/x3d/castlefields_x3devent.inc (line 47).

This item has no description.

Source: scene/x3d/castlefields_x3devent.inc (line 50).

This only reads (optional) "IS" clause of the event, as may occur in VRML nodeBodyStatement.

Source: scene/x3d/castlefields_x3devent.inc (line 64).

This item has no description. Showing description inherited from TX3DFileItem.SaveToStream.

Save to stream.

Source: scene/x3d/castlefields_x3devent.inc (line 66).

This item has no description. Showing description inherited from TX3DFileItem.SaveToXml.

How is this saved to X3D XML encoding. This determines when SaveToStream is called. It also cooperates with some SaveToStream implementations, guiding how the item is actually saved. By default it is sxChildElement.

Source: scene/x3d/castlefields_x3devent.inc (line 67).

Send a value to event. For input fields, this is used by routes, scripts etc. to send an event to a field. For output fields, this is used by node itself to send event to routes, scripts etc.

Field must be non-nil, of class FieldClass.

The Field instance doesn't become owned in any way by the TX3DEvent. That is, it's the caller responsibility to free the Field instance at any comfortable time, possibly right after calling Send.

Overloaded versions without explicit Time parameter just take time from ParentNode.Scene.GetTime. If ParentNode is Nil (which should not happen with normal fields within nodes) or if ParentNode.Scene is Nil (which may happen only if events processing is not turned on, that is TCastleSceneCore.ProcessEvents is False) then event is not send.

Source: scene/x3d/castlefields_x3devent.inc (line 90).

This item has no description.

Source: scene/x3d/castlefields_x3devent.inc (line 91).

Add notification about receiving new value. For input events, these are used by node itself to listen to events send to it. For output events, these are used by routes, scripts to listen to events occuring.

When you handle this callback to send another X3D event, you should pass around the same Time value. This makes sure that X3D route loop detection mechanism works fine. For example, here's how handling TimeSensor.elapsedTime_receive event sends fraction_changed event:

procedure TTimeSensorNode.EventElapsedTimeReceive(
  const Event: TX3DEvent; const Value: TX3DField; const Time: TX3DTime);
var
  Fraction: Single;
begin
  if FdEnabled.Value then
  begin
    Fraction := ...; // doesn't matter here how this is calculated
    // Pass "Time" parameter further by a call below
    Eventfraction_changed.Send(Fraction, Time);
  end;
end;

All callbacks registered here are simply called by Send method.

Source: scene/x3d/castlefields_x3devent.inc (line 120).

Remove notification (previously added by AddNotification) about receiving new value.

This is guaranteed to work correctly even if we're right now in the middle of this event's processing (which means that we may be iterating over a list of notifications). The handler may be actually removed a bit later (when it's safe).

Note that adding a notification two-times makes it called two times. Removing a notification removes one copy of a notification, so it should then be removed two-times too.

Source: scene/x3d/castlefields_x3devent.inc (line 133).

Is anything actually listening on this events Send?

Sometimes, even preparing a value to Send is quite time-consuming (example: CoordinateInterpolator, where a long MFVec3f value has to be computer). Then checking SendNeeded is useful: if SendNeeded = False, you know that there's no point in preparing Value to send, because actually Send will do nothing.

For example, event out to which no ROUTE is connected, and no Script can listen to it.

For now, this simply returns whether any callback is registered by AddNotification.

Source: scene/x3d/castlefields_x3devent.inc (line 148).

Assign from another event. The FieldClass and InEvent is copied.

The notifications (from AddNotification) and ParentExposedField are not copied, since they shouldn't be copied so easily (ParentExposedField is related to hierarchy of containers, copying notification would be surprising to the notification listener).

Source: scene/x3d/castlefields_x3devent.inc (line 157).

Position of this item within parent VRML/X3D node, used for saving the VRML/X3D graph to file. Default value -1 means "undefined".

For normal usage and processing of VRML graph, this is totally not needed. This position doesn't dictate actual meaning of VRML graph. If you're looking to change order of nodes, you probably want to rather look at something like ReplaceItems within TMFNode or such.

This field is purely a hint when encoding VRML file how to order VRML items (nodes, fields, routes, protos) within parent node or the VRML file. Reason: VRML allows non-unique node names. Each DEF XXX overrides all previous ("previous" in lexical sense, i.e. normal order of tokens in the file) DEF XXX with the same XXX, thus hiding previous node name "XXX". This means that when saving VRML file we have to be very careful about the order of items, such that e.g. all routes are specified when appropriate node names are bound.

This is a relative position, relative to other PositionInParent value of other TX3DFileItem items. So it's not necessary to keep all PositionInParent different or successive within some parent. When saving, we will sort everything according to PositionInParent.

See e.g. ../../../demo_models/x3d/tricky_def_use.x3dv for tests of some tricky layout. When reading such file we have to record PositionInParent to be able to save such file correctly.

Source: scene/x3d/castlefields_x3dfileitem.inc (line 71).

Name of the field or event.

Most fields/events are inside some X3D node, and then they have a non-empty name. But in some special cases we also use temporary fields with an empty name.

Note that you cannot change this after object creation, since Name is used for various purposes (like to generate names for TX3DField.ExposedEvents).

Note that this property is deliberately not called Name. In the future, this class may descend from the standard TComponent class, that defines a Name field with a special restrictions (it must be a valid Pascal identifier), which cannot apply to X3D node names (that can have quite free names, see http://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/grammar.html ). We don't want to confuse these two properties.

Source: scene/x3d/castlefields_x3dfieldorevent.inc (line 67).

Warning: this symbol is deprecated: use X3DName

This item has no description.

Source: scene/x3d/castlefields_x3dfieldorevent.inc (line 68).

X3D node containing this field/event. This must always contain an instance of TX3DNode class (although it cannot be declared such, since X3DFields unit cannot depend on X3DNodes interface).

It may be Nil for special fields/events when parent node is unknown.

Source: scene/x3d/castlefields_x3dfieldorevent.inc (line 76).

"IS" clauses of this field/event, used when this field/event is inside prototype definition.

This is an array, as one item may have many "IS" clauses (for a field, only one "IS" clause should refer to another field; but you can have many "IS" clauses connecting events, also exposedField may have "IS" clause that should be interpreted actually as links to it's exposed events). See e.g. demo_models/x3d/proto_events_test_3.x3dv.

Note that having "IS" clauses doesn't mean that the field should be considered "without any value". This is not a good way of thinking, as an exposed field may have an "IS" clause, but linking it to an event, and thus such field has it's value (default value, if not specified in the file), event though it also has an "IS" clause. Although there is TX3DField.ValueFromIsClause, which indicates whether current value was obtained from "IS" clause.

To be able to significantly optimize memory, we do not expose IsClauseNames as TCastleStringList. Instead operate on them only using below functions. Note that IsClauseNamesAssign can also accept Nil as parameter.

Source: scene/x3d/castlefields_x3dfieldorevent.inc (line 101).

For fields contained in TX3DInterfaceDeclaration.

This should always be Nil (if the field is normal, standard field, not coming from interface declaration in X3D file) or an instance of TX3DInterfaceDeclaration. (But it cannot be declared such, since TX3DInterfaceDeclaration is not known in this unit).

Source: scene/x3d/castlefields_x3dfieldorevent.inc (line 154).

This item has no description.

Source: scene/x3d/castlefields_x3devent.inc (line 57).

Is it "in" or "out" event ?

Source: scene/x3d/castlefields_x3devent.inc (line 60).

If this event is an exposed event belonging to some field, this references parent field. Otherwise it's Nil.

Source: scene/x3d/castlefields_x3devent.inc (line 71).