Class TVRMLLexer

See TVRMLNode.WWWBasePath for a description of this field.

This field is not used anywhere in the Lexer but it MUST be defined to something sensible. It is just some information "carried with" the lexer. We will use it when we parse nodes.

This is used when parsing to keep current namespace for DEF/USE.

NodeNameBinding jest lista bez duplikatow okreslajaca wszystkie dotychczasowe nazwy node'ow razem z ich instancjami. Jezeli kilka instancji mialo takie samo NodeName to na liscie znajduje sie ostatni z nich (ostatni w sensie pozycji w pliku, czy raczej w strumieniu tokenow Lexera). Tym samym jest chyba jasne do czego uzywamy NodeNameBinding : do realizacji konstrukcji "USE <nodename>". Procedura ParseNode nie moze modyfikowac tej listy, to zadania ma wykonywac TVRMLNode.Parse.

This is used when parsing to keep current namespace of prototypes.

NextToken reads next token from stream, initializing appropriately all Token* properties. For comfort, this returs the Token value.

uzywaj gdy wiesz ze nastepny token MUSI byc vtName i zeby w zwiazku z tym lekser odczytal nastepny token jako vtName. Pamietaj ze moze to powodowac odczytanie jako vtName czegos co nie jest poprawna nazwa node'a w VRML'u ! Ale moze byc uzyteczne jesli jakis inny program zapisywal plik VRML'a nie patrzac na to czy tworzy prawidlowe czy nie nazwy VRML'a (np. mgf2inv potrafi zapisac nazwe "0" (tak jest, zero, co oczywiscie zostanie odczytane jako vtInteger), gdzie indziej znalazlem przykladowe VRMLe z nazwa node'a "Crab!" (tak, z "!" i cudzyslowem)).

Uzywajac tej procedury bedziesz w stanie odczytac takie VRMLe ze zlymi nazwami node'ow (pamietajac ze zawsze przed nazwa node'a jest USE lub DEF wiec wiadomo kiedy nalezy sie spodziewac vtName i wtedy wlasnie trzeba uzyc NextTokenForceVTName.)

Wyjatek EParserError (bo to przeciez blad parsowania, nie leksera) jesli mimo wszystko nie uda sie odczytac tokenu vtName.

Similiar to NextTokenForceVTName: use this like a shortcut for NextToken; CheckTokenIs(vtString); but it is NOT equivalent to such instructions. This is because VRML 1.0 allowed rather strange thing: string may be not enclosed in double quotes if it does not contain a space. This "feature" is not present in VRML 97, but, unfortunately, I'm trying to handle VRML 1.0 here so I have to conform to this specification. In particular, Blender generates VRML 1.0 files with Texture2.filename fields not enclosed in double quotes. So this "feature" is actually used by someone... So I have to implement this.

Usual NextToken will not be able to return vtString if it approaches a string not enclosed in double quotes. But THIS function will be able to handle it. So always use this function when you expect a string, this ensures that we will correctly parse any valid VRML 1.0 file.

(unfortunately I'm not doing this now when parsing MFString, this would just require too "unclean" code; I'm using this function only before calling parse on SFString field from TVRMLNode.Parse.)

Returns if Token is vtKeyword and TokenKeyword is given Keyword.

skonstruuj tekstowy opis tokenu ktory nadaje sie do pokazania userowi.

Check is token = Tok, if not -> parser error "expected token >>tok<<". You can provide your own description for Tok or default desciption for token will be used.

Standard constructor. After constructor call, VRMLVerMajor and VRMLVerMinor are already set, it's checked that file is not compressed by gzip, and the first Token is already read.

Exceptions raised

EVRMLGzipCompressed

If the Stream starts with gzip file header.

to po prostu strumien ktory dostalismy jako parametr konstruktora. Nie mozesz na nim operowac kiedy juz zainicjowales lexera ! Ale mozesz np. sprawdzic jego Position aby wiedziec gdzie mniej wiecej bylismy w strumieniu gdy wystapil blad lexera.

These indicate VRML version, as recorded in VRML file header.

The only versions allowed by any VRML specifications are 1.0 and 2.0. Moreover we handle Inventor 1.0 ascii, then we set VRMLVerMajor and VRMLVerMinor both to 0 (as historically Inventor is a predecessor to VRML 1.0).

Token na jakim aktualnie stoimy. Odpowiednie pola TokenKeyword, TokenName, TokenFloat i TokenInteger maja defined wartosci tylko jezeli typ tokenu jest odpowiedni.

When Token = vtKeyword, TokenKeyword points to appropriate keyword. Jezeli VRMLVersion = 1.0 to na pewno TokenKeyword in VRML10Keywords. Innymi slowy, gdy czytamy VRML 1.0 np. string "PROTO" zostanie potraktowany jako token Name, nie keyword. I tak jest dobrze.

When Token = vtName, TokenName contains appropriate VRML name.

Name syntax as in specification on page 24 (really 32 in pdf) of vrml97specification.pdf. It can be a user name for something (for a node, for example) but it can also be a name of a node type or a node field or an enumerated field constant ... it can be anything except keyword.

Note that this is supposed to contain UTF-8 encoded string for VRML 2.0.

When Token = vtFloat or vtInteger, TokenFloat contains a value of this token.

VRML float token corresponds to Pascal Float type, in VRML it's expressed in the followin form:

        [("-"|"+")]
        (digit+ [ "." digit+ ] | "." digit+)
        [ "e"|"E" [("-"|"+")] digit+ ]
      

For vtInteger you have the same thing in TokenInteger, TokenFloat is also initialized to the same value for your comfort (every integer value is also a float, after all).

When Token = vtInteger, TokenInteger contains appropriate value.

VRML integer token corresponds to Pascal Int64 type, in VRML it's expressed in the followin form:

        (form : [("-"|"+")] ("0x" digit_hex+ | [1-9]digit_decimal* | 0 digit_octal+) )