Stephen Collyer wrote:
David Bertoni wrote:
Stephen Collyer wrote:
I guess you mean setDocumentLocator() ?
So to use this, I create a Locator object, pass it to
setDocumentLocator(). Then the Xerces parser code will
set the appropriate error info, which I can retrieve
in, say, the warning(), error() methods of an error
handler class ?
Yes, that's the right call, but you've reversed what you need to do.
Your ContentHandler implementation should override setDocumentLocator()
and store that pointer.
Right. So the only thing that needs to happen in the overridden
method is the storing of the pointer that's passed in ?
Yes, that's it. In fact, that's what the documentation for the function
states:
* By default, do nothing. Application writers may override this
* method in a subclass if they wish to store the locator for use
* with other document events.
Then, during parsing callbacks (and only during
them), you can call the accessor functions to get the information you
need.
By "parsing callbacks" I guess you mean start_document(),
start_element() and so on ?
Yes. startDocument, startElement, endElement, etc. are all parsing
callback functions.
The parser has to provide you with an instance of a Locator,
since it's parsing the document.
Well, I guess it could work the other way round - the
implementation could expect the Locator* to be passed when
the parser is created.
If you consider the information that the Locator provides, I think you'll
agree it would be inefficient to have the parser report ever detail of the
parse to it. The way it's implemented, the application can poll for
information only when it needs it.
However, given that the parser creates
the Locator, then I suppose it also deletes it ? i.e. the
content handler need not do that ?
No, you must not. The Locator belongs to the parser instance.
Dave
