It looks like that code handles passing OpenDX objects back from OpenDX to
the application. You need a lot of stuff to un-serialize the objects.
For example, the user can install a handler to be called whenever an error
message is produced by OpenDX, or when OpenDX executes DXLOutput.
I think that if you want to use that functionality, you would link with
both libDXL.a and libDXlite.a. I don't think that the functionality has
to be incorporated into DXL. Is that a problem for libtool?
Greg
David Thompson
<[EMAIL PROTECTED]> To:
[email protected]
Sent by: cc:
[EMAIL PROTECTED] Subject: [opendx-dev] libDXL
trying to build
son.ibm.com
07/15/2002 05:01 PM
Please respond to
opendx-dev
Okay,
I'm looking into libtoolizing libDXL.xx, and have really run into a
snag. The included file object.o adds the function _dxfExportBin_FP,
which causes the need to include a ton more files--I'm not sure how
many yet (I've currently tracked down at least 5 [fileio.c, memory.c,
edfdata.c, message.c, and hash.c]). I guess what I'm asking is, what
does object.c provide us that is required within DXLink? Looking at
the 3.1.4 programmer's guide, the functions that are included within
object.c are not listed as part of DXLink. Was this something that
was being added for a later release? Does anybody have an objection
to trying to replicate the _dxfExportBin_FP function without the need
to include half of libDX for use within DXL/object.c?
David
--
.............................................................................
David L. Thompson Visualization and Imagery Solutions,
Inc.
mailto:[EMAIL PROTECTED] 5515 Skyway Drive, Missoula, MT 59804
Phone : (406)257-8530
