Castle Game Engine: X3DFields: Class TX3DFileItem

# Class TX3DFileItem
Description | Hierarchy | Fields | Methods | Properties
## Unit X3DFields ## Declaration `type TX3DFileItem = class(TNonRefCountedInterfacedPersistent)` ## Description Base class for any item within VRML/X3D file: a node, a field, a route, a prototype etc. We need a common base class for all such things to store PositionInParent. About ancestry: TX3DFieldOrEvent make use of Assign mechanism and so need to descend from TPersistent. TX3DNode make use of interfaces and so must descend from something like TNonRefCountedInterfacedXxx. These are the only reasons, for now, why this descends from TNonRefCountedInterfacedPersistent. ## Hierarchy TPersistent TNonRefCountedInterfacedPersistent TX3DFileItem ## Overview ### Methods
| `constructor Create;`
| `procedure SaveToStream(Writer: TX3DWriter); virtual; abstract;`
| `function SaveToXml: TSaveToXmlMethod; virtual;`
### Properties
| `property PositionInParent: Integer read FPositionInParent write FPositionInParent default -1;`
## Description ### Methods
| `constructor Create;`
| `procedure SaveToStream(Writer: TX3DWriter); virtual; abstract;`
Save to stream.
| `function SaveToXml: TSaveToXmlMethod; virtual;`
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.
### Properties
| `property PositionInParent: Integer read FPositionInParent write FPositionInParent default -1;`
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.
Generated by PasDoc 0.13.0 on 2015-06-15 04:43:13