Hello Johannes,
On Fri, Sep 11, 2009 at 4:00 AM, Johannes Brunen <[email protected]> wrote:
> "Carsten Neumann" <[email protected]> schrieb im
> Newsbeitrag news:[email protected]...
>>
>> you can extend the OSB loader to have some special handling of old
>> classes instead of just using the default code path for your attachment.
>> We use this for example to convert TextureChunk to a pair of
>> TextureObjChunk and TextureEnvChunk.
>>
> Am I correct that this does automatically imply that I need to write a new
> attachment class, or is there a way to reuse the old class carrying a
> modified field type?
you can keep the name of your attachment type the same for 2.0, just
change the type of the field in question to MFUInt64. When reading the
field in question you need to convert them if it is an 1.x osb file;
for a 2.0 osb you don't need any special handling.
> Do I have to write some OSGOSBHandleMyAttachment class derived from
> OSBCommonElement? What are the tasks I do have to solve?
you mainly need to implement read(), perhaps postRead(), since writing
should not need any special handling there is no need to override
preWrite()/write().
The OSBCommonElement is mainly meant as a helper, it contains
functions that can read the header for a container and all or some of
the fields.
Perhaps the best way to get started is by taking OSGImageElement as an
example, as it also makes the distinction between reading a 1.x and a
2.0 osb...
>> One thing that is a bit tricky about the OSB loader is the way pointers
>> are stored/handled. On disc a pointer is stored as the id of the
>> pointed-to container, when loading a map between on-disc ids and system
>> ids is built and for each pointer field a data structure with the on
>> disc ids is filled. After loading the on disc ids are resolved to system
>> ids and the pointer fields of the containers are filled with the correct
>> values.
>> Please let me know if you need more info on the OSB loader and/or how to
>> extend it to handle your case.
>>
> Yes, some background information would be helpful in this context.
you probably don't have to deal with the pointer mapping stuff from
what you described, it only applies to pointers to FieldContainers.
The easiest way to handle this though is to use the functions in
OSBCommonElement that know how to read pointer fields (e.g.
readPtrSingleField(), readPtrMultiField(), readAttachmentMapField() ).
These helpers are also comparatively well documented ;)
Cheers,
Carsten
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
