Hello Carsten, I'm back to this problem and need some more information.
"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? Do I have to write some OSGOSBHandleMyAttachment class derived from OSBCommonElement? What are the tasks I do have to solve? > > 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. Any help is really appreciated. Best, Johannes ------------------------------------------------------------------------------ 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
