Loading ...
Sorry, an error occurred while loading the content.
 

RE: [cc2-dev-l] FCW loader

Expand Messages
  • Sasha Bilton
    ... True, but you could provide a tool, like a lot of the 3D games do these days, for making stuff within which is something that produces binary XML for your
    Message 1 of 16 , Jan 25, 2001
      > From: Max Skibinsky [mailto:lordmax@...]
      > > There is a tech called binary XML which is compressed XML and
      > makes files
      > > much smaller. A number of people are working on libraries that
      > translate SAX
      >
      > That is nice tech, but won't it make final files not human
      > readable? And that is in my view one of
      > the *major* XML advantages.

      True, but you could provide a tool, like a lot of the 3D games do these
      days, for making stuff within which is something that produces binary XML
      for your real time engine.

      > > files either. Finally don't forget that you might use XSL to
      > transform your
      > > big XML into more useful file formats for yourself at the
      > production stage.
      >
      > As far as i know all existing XSL:T processors right now operate
      > only by loading XML completely into
      > the memory. XT - yes, Saxon - yes, MSXML/XSL:T - yes, and you can
      > do XSL:T only via DOM. Now, you
      > don't really want to use DOM to load 10 Mb files ;) So
      > theorecticaly its ok, practicaly for
      > map-related tasks its not possible right now to bring XML/XSL:T into play.

      Again, loading and transform 10megs is a pain for real-time but not for
      preprocessing. Hell I bet XSLT gurus could write a XSLT file that convert
      CCML into FCW. Finally is there any good reason why you couldn't split map
      files up into smaller parts? One file per layer or symbol type say.

      > > Anyway, I'm more into processing 'CCML' in less performance
      > than you need,
      > > however as an XML evangelist I really think you'll find that having
      > > something that reads ands writes XML will help you guys out in further
      > > projects.
      >
      > On small maps or simple constructs - like symbols libraires - XML
      > may work. But i don't see big
      > benefits in switching map formats to XML completely on the long
      > run. Anyway, moot point, seems no
      > one have this loader code.... If i will get free day or two i
      > will write some XML dump, to check
      > what kinda of files it will produce.

      Well if you swap it round, I agree. That is switching over from FCW to XML
      in the sort term might not see instant returns, but in the long term I doubt
      any CAD system can afford to avoid XML. Once Vector Mark Language is
      properly embedded in all webbrowsers I can't see a good arguement for
      supplying a transform from say FastCAD to VML. Imagine having maps, 3d or
      2d, on web pages that you can zoom, rotate, hide layers and link from. You
      don't have to do away with FCW completely, it's a good format if you don't
      want to import your work into other systems.

      The only thing stopping me from coding this up (apart from time) is that
      I've no knowledge of FCW files and looking at the docs it would take a fair
      amount of effort to pick up the more complex parts of it.
    • Claudi Paniagua
      Hi all Regarding the XML format discussion I thought it might be helpful to note that there s a W3C candidate recomendation for an XML syntax to describe
      Message 2 of 16 , Jan 25, 2001
        Hi all

        Regarding the XML format discussion I thought it might
        be helpful to note that there's a W3C candidate
        recomendation for an XML syntax to describe vector
        graphics, called SVG (Scalable Vector Graphics).

        There's a plug-in from adobe to render SVG files in a
        browser. That could add value to FCW maps, they could
        be manipulated from browsers!

        I admit that the file size issue is a caveat, but
        there surely must be some way to organize big files
        out of smaller ones (i.e. per layers)

        Olorin


        __________________________________________________
        Do You Yahoo!?
        Yahoo! Auctions - Buy the things you want at great prices.
        http://auctions.yahoo.com/
      • Max Skibinsky
        ... True, but then it won t be any different from zillion of proprietory existing text and 3D formats. XML is so popular because its human-readable
        Message 3 of 16 , Jan 31, 2001
          > > That is nice tech, but won't it make final files not human
          > > readable? And that is in my view one of
          > > the *major* XML advantages.
          >
          > True, but you could provide a tool, like a lot of the 3D games do these
          > days, for making stuff within which is something that produces binary XML
          > for your real time engine.

          True, but then it won't be any different from zillion of proprietory existing text and 3D formats.
          <IMHO> XML is so popular because its human-readable *and* machine-readable text file format which
          anyone can read/fix in his notepad if he wanted. </IMHO> As soon as you start making it dependent on
          prorietory editors - won't be any different from say 3D Max ASE text-based 3D format. The editor
          will limit the scope of "acceptable" XML for final application - and thus making it in fact close
          format.

          > > theorecticaly its ok, practicaly for
          > > map-related tasks its not possible right now to bring XML/XSL:T into play.
          > Again, loading and transform 10megs is a pain for real-time but not for

          Note - if you are using MS XSL:T processor (and what else to use if you want to be sure the engine
          will be supported in future...) you will can do it via DOM only. DOM will create first 5-10x
          overhead on XML - e.g. 50-100Mb in memory. Then after applying XSL:T script you will have second DOM
          with result. I.e. to process analog of 1Mb binary data, you may need up to 200 Mb memory in
          real-time. My solution for now is only keep XML for principal logical data & human readable data,
          but everything what was binary, stays binary for now. <IMHO> FCW and maps was never human readable,
          never would benefit from being human readable. Its their visualization what is human readable.
          </IMHO>

          > preprocessing. Hell I bet XSLT gurus could write a XSLT file that convert
          > CCML into FCW. Finally is there any good reason why you couldn't split map

          Most likely. If they want to use 200 mb to produce 1 mb binary file.

          > files up into smaller parts? One file per layer or symbol type say.

          Technicaly - yes, its doable - but why bother? Its not solving the size problem, just masking it. If
          i want to load, or process the whole map - i *need* the whole map. One way or another whole map will
          have to parse through my reader, memory, or whatever. Split by layers - you will still have to load
          virtually all layers, because each of them may have some data about this point on map. Split by
          cells - if they are too large, they still can be big files (user placed 200 flowers in that small
          groove), if they are too small - they visualization in 3D will require loading adjusted cells (your
          hero casts "Levitate" goes up and looks around in fair weather). Finaly multiple files is just
          pain - you no longer can just drag and drop your map to a friend which he can immidiately open in
          email. He will have to create a directory, save all your layer-XML-files there, then understand
          which one is the "main" file, engine resolve possible lost files etc, etc. Lots of pain and no gain
          at all (maps will be same as before after all).

          > Well if you swap it round, I agree. That is switching over from FCW to XML
          > in the sort term might not see instant returns, but in the long term I doubt
          > any CAD system can afford to avoid XML. Once Vector Mark Language is
          > properly embedded in all webbrowsers I can't see a good arguement for
          > supplying a transform from say FastCAD to VML. Imagine having maps, 3d or
          > 2d, on web pages that you can zoom, rotate, hide layers and link from. You

          will work very well for small and simple maps. Large maps - on top of downloading 10 mb file vs. 1mb
          binary you will be foreced to use generic browser renderer which most likely will be very slow.
          Theoreticaly XML helps here, but practicaly if i would want to do that, i would simply write
          DirectX-based ActiveX client-side control, which would load binary file and draw it with hardware
          acceleration and use DirectDraw/D3D vs. relying on browser one. We kinda steped on that while doing
          Java 3D applet for overseer. The speed is abysmal for practical implementations.

          - Max
        • Mike Riddle
          Hi - There is a prototype toolkit for directly reading FCW files from standalone (non-XP) C programs available in the file:
          Message 4 of 16 , Feb 2, 2001
            Hi - There is a prototype toolkit for directly reading FCW files from
            standalone (non-XP) C programs available in the file:

            www.fastcad.com/downloads/tktest.zip

            You should use the database definitions (.h or .cpy files)
            in the latest XP toolkit with it, but the actual DLL contained there
            gives direct access to the low-level drawing list management routines.
            They are an early version from V7, and use a more object-oriented
            design, but work fine with V6 using the correct data structures.
            This may be a useful starting point.

            On XML: Our plans go to SVG files, which are sponsered by w3c,
            and are text readable. They will allow most of the goals stated here.
            We plan SVG support first for V7, later for V6, and are basically
            waiting for the big guys to include viewers in their next IE/Netscape
            releases so that customers won't have separate installs for it.

            I think this will do most of what we are all wanting. As to the speed,
            well we all are waiting for broadband to spread, but it will do so.
            We should plan on it. Until then, the FCW file format is one of the
            tightest around for what it does. It was designed that way as file size
            directly impacts memory usage, and that impacts speed. I doubt
            that there is anything out there that can do better, or close, with regard
            to file size, than a compressed FCW file. A packed zip of the file
            only saves an additional 5%, and can not be directly accessed.

            If anyone tries to use the TKTEST files, and has questions, they
            can direct inquiries to me.

            Mike Riddle

            Max Skibinsky wrote:

            > > > That is nice tech, but won't it make final files not human
            > > > readable? And that is in my view one of
            > > > the *major* XML advantages.
            > >
            > > True, but you could provide a tool, like a lot of the 3D games do these
            > > days, for making stuff within which is something that produces binary XML
            > > for your real time engine.
            >
            > True, but then it won't be any different from zillion of proprietory existing text and 3D formats.
            > <IMHO> XML is so popular because its human-readable *and* machine-readable text file format which
            > anyone can read/fix in his notepad if he wanted. </IMHO> As soon as you start making it dependent on
            > prorietory editors - won't be any different from say 3D Max ASE text-based 3D format. The editor
            > will limit the scope of "acceptable" XML for final application - and thus making it in fact close
            > format.
            >
            > > > theorecticaly its ok, practicaly for
            > > > map-related tasks its not possible right now to bring XML/XSL:T into play.
            > > Again, loading and transform 10megs is a pain for real-time but not for
            >
            > Note - if you are using MS XSL:T processor (and what else to use if you want to be sure the engine
            > will be supported in future...) you will can do it via DOM only. DOM will create first 5-10x
            > overhead on XML - e.g. 50-100Mb in memory. Then after applying XSL:T script you will have second DOM
            > with result. I.e. to process analog of 1Mb binary data, you may need up to 200 Mb memory in
            > real-time. My solution for now is only keep XML for principal logical data & human readable data,
            > but everything what was binary, stays binary for now. <IMHO> FCW and maps was never human readable,
            > never would benefit from being human readable. Its their visualization what is human readable.
            > </IMHO>
            >
            > > preprocessing. Hell I bet XSLT gurus could write a XSLT file that convert
            > > CCML into FCW. Finally is there any good reason why you couldn't split map
            >
            > Most likely. If they want to use 200 mb to produce 1 mb binary file.
            >
            > > files up into smaller parts? One file per layer or symbol type say.
            >
            > Technicaly - yes, its doable - but why bother? Its not solving the size problem, just masking it. If
            > i want to load, or process the whole map - i *need* the whole map. One way or another whole map will
            > have to parse through my reader, memory, or whatever. Split by layers - you will still have to load
            > virtually all layers, because each of them may have some data about this point on map. Split by
            > cells - if they are too large, they still can be big files (user placed 200 flowers in that small
            > groove), if they are too small - they visualization in 3D will require loading adjusted cells (your
            > hero casts "Levitate" goes up and looks around in fair weather). Finaly multiple files is just
            > pain - you no longer can just drag and drop your map to a friend which he can immidiately open in
            > email. He will have to create a directory, save all your layer-XML-files there, then understand
            > which one is the "main" file, engine resolve possible lost files etc, etc. Lots of pain and no gain
            > at all (maps will be same as before after all).
            >
            > > Well if you swap it round, I agree. That is switching over from FCW to XML
            > > in the sort term might not see instant returns, but in the long term I doubt
            > > any CAD system can afford to avoid XML. Once Vector Mark Language is
            > > properly embedded in all webbrowsers I can't see a good arguement for
            > > supplying a transform from say FastCAD to VML. Imagine having maps, 3d or
            > > 2d, on web pages that you can zoom, rotate, hide layers and link from. You
            >
            > will work very well for small and simple maps. Large maps - on top of downloading 10 mb file vs. 1mb
            > binary you will be foreced to use generic browser renderer which most likely will be very slow.
            > Theoreticaly XML helps here, but practicaly if i would want to do that, i would simply write
            > DirectX-based ActiveX client-side control, which would load binary file and draw it with hardware
            > acceleration and use DirectDraw/D3D vs. relying on browser one. We kinda steped on that while doing
            > Java 3D applet for overseer. The speed is abysmal for practical implementations.
            >
            > - Max
            >
            >
            > To Post a message, send it to: cc2-dev-l@...
            > To Unsubscribe, send a blank message to: cc2-dev-l-unsubscribe@...
          • Max Skibinsky
            Hi! Yay! Thanks, Mike! That rocks ;) - Max ... From: Mike Riddle To: Sent: Friday, February 02, 2001 12:37 AM
            Message 5 of 16 , Feb 2, 2001
              Hi!

              Yay! Thanks, Mike! That rocks ;)

              - Max

              ----- Original Message -----
              From: Mike Riddle <mriddle@...>
              To: <cc2-dev-l@yahoogroups.com>
              Sent: Friday, February 02, 2001 12:37 AM
              Subject: Re: [cc2-dev-l] FCW loader


              > Hi - There is a prototype toolkit for directly reading FCW files from
              > standalone (non-XP) C programs available in the file:
              >
              > www.fastcad.com/downloads/tktest.zip
            • Max Skibinsky
              Few questions. How do i scan/access entities in loaded file? IDList::DLScan(void) has no parameters to put callback in... Also, how you would recomend to
              Message 6 of 16 , Feb 3, 2001
                Few questions. How do i scan/access entities in loaded file? IDList::DLScan(void) has no parameters
                to put callback in... Also, how you would recomend to access FCW file color table (RGB vals),
                linestyle table and layer name <-> id table? Other then that IDList methods are quite clear, thanks
                again!

                - Max

                --- In cc2-dev-l@y..., Mike Riddle <mriddle@u...> wrote:
                > Hi - There is a prototype toolkit for directly reading FCW files from
                > standalone (non-XP) C programs available in the file:
                >
                > www.fastcad.com/downloads/tktest.zip
              • Mike Riddle
                The file FCWTK.H in the TKTEST directory (where you put the FCWTK) has the prototype for DLScan and its callback. The various infoblock records (see the V6 or
                Message 7 of 16 , Feb 3, 2001
                  The file FCWTK.H in the TKTEST directory (where you put the FCWTK)
                  has the prototype for DLScan and its callback.

                  The various infoblock records (see the V6 or V7 xptoolkit files for their
                  definition) hold the fill style and line style data. Infoblocks are entity type 0,
                  and have a subtype IBType which identifies which one each record is.
                  This is defined in copy files for each infoblock. Note that record type id
                  numbers differ from V6 to V7.

                  There is no color palette data saved with each V6 file. I have uploaded the
                  standard color table to www.fastcad.com/downloads/palette.cpy. V7
                  does contain a copy in the CMAPIB Infoblock (entity type 0) record.

                  Mike

                  Max Skibinsky wrote:

                  > Few questions. How do i scan/access entities in loaded file? IDList::DLScan(void) has no parameters
                  > to put callback in... Also, how you would recomend to access FCW file color table (RGB vals),
                  > linestyle table and layer name <-> id table? Other then that IDList methods are quite clear, thanks
                  > again!
                  >
                  > - Max
                  >
                  > --- In cc2-dev-l@y..., Mike Riddle <mriddle@u...> wrote:
                  > > Hi - There is a prototype toolkit for directly reading FCW files from
                  > > standalone (non-XP) C programs available in the file:
                  > >
                  > > www.fastcad.com/downloads/tktest.zip
                  >
                  >
                  > To Post a message, send it to: cc2-dev-l@...
                  > To Unsubscribe, send a blank message to: cc2-dev-l-unsubscribe@...
                • Max Skibinsky
                  Hi! Sorry if i m missing something very obvious, but to make sure we are on same page... Thats the FCWTK.H in the zip file on your server: -- file start -- //
                  Message 8 of 16 , Feb 3, 2001
                    Hi!

                    Sorry if i'm missing something very obvious, but to make sure we are on same page... Thats the
                    FCWTK.H in the zip file on your server:
                    -- file start --
                    // FCWTK.H
                    struct IDList
                    {
                    virtual void __stdcall DLDestroy(void) = 0;
                    virtual pENTREC __stdcall DLApnd(void* pENTREC) = 0;
                    virtual pENTREC __stdcall DLApndE(int,void* pENTREC) = 0;
                    virtual pENTREC __stdcall DLClone(void* pENTREC) = 0;
                    virtual void __stdcall DLErase(void* pENTREC) = 0;
                    virtual void __stdcall DLUnErase(void* pENTREC) = 0;
                    virtual pENTREC __stdcall DLReplace(void*,void*) = 0;
                    virtual void __stdcall DLDelete(void* pENTREC) = 0;
                    virtual pENTREC __stdcall DLResize(void* pENTREC,int) = 0;
                    virtual int __stdcall DLSave(void) = 0;
                    virtual int __stdcall DLLoad(void) = 0;
                    virtual int __stdcall DLScan(void) = 0;
                    virtual void __stdcall DLEmpty(void) = 0;
                    virtual void __stdcall DLRename(char*) = 0;
                    };
                    IDList* _stdcall CreateDList(char*,int);
                    -- end of file --

                    if IDList::DLScan(void) is scanning function, how do i set the callback? Thanks for the rest, just
                    what we needed!

                    - Max

                    ----- Original Message -----
                    From: Mike Riddle <mriddle@...>
                    To: <cc2-dev-l@yahoogroups.com>
                    Sent: Saturday, February 03, 2001 9:48 PM
                    Subject: Re: [cc2-dev-l] FCW loader


                    > The file FCWTK.H in the TKTEST directory (where you put the FCWTK)
                    > has the prototype for DLScan and its callback.
                    >
                    > The various infoblock records (see the V6 or V7 xptoolkit files for their
                    > definition) hold the fill style and line style data. Infoblocks are entity type 0,
                    > and have a subtype IBType which identifies which one each record is.
                    > This is defined in copy files for each infoblock. Note that record type id
                    > numbers differ from V6 to V7.
                    >
                    > There is no color palette data saved with each V6 file. I have uploaded the
                    > standard color table to www.fastcad.com/downloads/palette.cpy. V7
                    > does contain a copy in the CMAPIB Infoblock (entity type 0) record.
                    >
                    > Mike
                    >
                    > Max Skibinsky wrote:
                    >
                    > > Few questions. How do i scan/access entities in loaded file? IDList::DLScan(void) has no
                    parameters
                    > > to put callback in... Also, how you would recomend to access FCW file color table (RGB vals),
                    > > linestyle table and layer name <-> id table? Other then that IDList methods are quite clear,
                    thanks
                    > > again!
                    > >
                    > > - Max
                    > >
                    > > --- In cc2-dev-l@y..., Mike Riddle <mriddle@u...> wrote:
                    > > > Hi - There is a prototype toolkit for directly reading FCW files from
                    > > > standalone (non-XP) C programs available in the file:
                    > > >
                    > > > www.fastcad.com/downloads/tktest.zip
                    > >
                    > >
                    > > To Post a message, send it to: cc2-dev-l@...
                    > > To Unsubscribe, send a blank message to: cc2-dev-l-unsubscribe@...
                    >
                    >
                    >
                    > To Post a message, send it to: cc2-dev-l@...
                    > To Unsubscribe, send a blank message to: cc2-dev-l-unsubscribe@...
                    >
                  • Mike Riddle
                    Sorry: The TKTEST.ZIP I posted was an older one - it did not have the final version of the FCWTK.H file in it. I have just posted the correct file:
                    Message 9 of 16 , Feb 4, 2001
                      Sorry: The TKTEST.ZIP I posted was an older one - it did not have the
                      final version of the FCWTK.H file in it. I have just posted the correct
                      file:

                      www.fastcad.com/downloads/tktest.zip

                      Again, my apologies.
                      Mike

                      Max Skibinsky wrote:

                      > Hi!
                      >
                      > Sorry if i'm missing something very obvious, but to make sure we are on same page... Thats the
                      > FCWTK.H in the zip file on your server:
                      > -- file start --
                      > // FCWTK.H
                      > struct IDList
                      > {
                      > virtual void __stdcall DLDestroy(void) = 0;
                      > virtual pENTREC __stdcall DLApnd(void* pENTREC) = 0;
                      > virtual pENTREC __stdcall DLApndE(int,void* pENTREC) = 0;
                      > virtual pENTREC __stdcall DLClone(void* pENTREC) = 0;
                      > virtual void __stdcall DLErase(void* pENTREC) = 0;
                      > virtual void __stdcall DLUnErase(void* pENTREC) = 0;
                      > virtual pENTREC __stdcall DLReplace(void*,void*) = 0;
                      > virtual void __stdcall DLDelete(void* pENTREC) = 0;
                      > virtual pENTREC __stdcall DLResize(void* pENTREC,int) = 0;
                      > virtual int __stdcall DLSave(void) = 0;
                      > virtual int __stdcall DLLoad(void) = 0;
                      > virtual int __stdcall DLScan(void) = 0;
                      > virtual void __stdcall DLEmpty(void) = 0;
                      > virtual void __stdcall DLRename(char*) = 0;
                      > };
                      > IDList* _stdcall CreateDList(char*,int);
                      > -- end of file --
                      >
                      > if IDList::DLScan(void) is scanning function, how do i set the callback? Thanks for the rest, just
                      > what we needed!
                      >
                      > - Max
                      >
                      > ----- Original Message -----
                      > From: Mike Riddle <mriddle@...>
                      > To: <cc2-dev-l@yahoogroups.com>
                      > Sent: Saturday, February 03, 2001 9:48 PM
                      > Subject: Re: [cc2-dev-l] FCW loader
                      >
                      > > The file FCWTK.H in the TKTEST directory (where you put the FCWTK)
                      > > has the prototype for DLScan and its callback.
                      > >
                      > > The various infoblock records (see the V6 or V7 xptoolkit files for their
                      > > definition) hold the fill style and line style data. Infoblocks are entity type 0,
                      > > and have a subtype IBType which identifies which one each record is.
                      > > This is defined in copy files for each infoblock. Note that record type id
                      > > numbers differ from V6 to V7.
                      > >
                      > > There is no color palette data saved with each V6 file. I have uploaded the
                      > > standard color table to www.fastcad.com/downloads/palette.cpy. V7
                      > > does contain a copy in the CMAPIB Infoblock (entity type 0) record.
                      > >
                      > > Mike
                      > >
                      > > Max Skibinsky wrote:
                      > >
                      > > > Few questions. How do i scan/access entities in loaded file? IDList::DLScan(void) has no
                      > parameters
                      > > > to put callback in... Also, how you would recomend to access FCW file color table (RGB vals),
                      > > > linestyle table and layer name <-> id table? Other then that IDList methods are quite clear,
                      > thanks
                      > > > again!
                      > > >
                      > > > - Max
                      > > >
                      > > > --- In cc2-dev-l@y..., Mike Riddle <mriddle@u...> wrote:
                      > > > > Hi - There is a prototype toolkit for directly reading FCW files from
                      > > > > standalone (non-XP) C programs available in the file:
                      > > > >
                      > > > > www.fastcad.com/downloads/tktest.zip
                      > > >
                      > > >
                      > > > To Post a message, send it to: cc2-dev-l@...
                      > > > To Unsubscribe, send a blank message to: cc2-dev-l-unsubscribe@...
                      > >
                      > >
                      > >
                      > > To Post a message, send it to: cc2-dev-l@...
                      > > To Unsubscribe, send a blank message to: cc2-dev-l-unsubscribe@...
                      > >
                      >
                      >
                      > To Post a message, send it to: cc2-dev-l@...
                      > To Unsubscribe, send a blank message to: cc2-dev-l-unsubscribe@...
                    • Max Skibinsky
                      Hi! Thanks, Mike! no problem at all, glad to have working version ;) - Max
                      Message 10 of 16 , Feb 4, 2001
                        Hi!

                        Thanks, Mike! no problem at all, glad to have working version ;)

                        - Max
                      • waldronate
                        I ll resurrect an ancient thread because it turns out that I don t have a current version of the header lying about anywhere. Is the corrected version of the
                        Message 11 of 16 , Dec 14 3:20 PM
                          I'll resurrect an ancient thread because it turns out that I don't
                          have a current version of the header lying about anywhere. Is the
                          corrected version of the FCWTK.H available anywhere? It's not on the
                          FastCAD URL listed below (but I didn't really expect it to be after
                          all this time).
                          Joe Slayton


                          --- In cc2-dev-l@yahoogroups.com, "Mike Riddle" <mriddle@u...> wrote:
                          > Sorry: The TKTEST.ZIP I posted was an older one - it did not have
                          the
                          > final version of the FCWTK.H file in it. I have just posted the
                          correct
                          > file:
                          >
                          > www.fastcad.com/downloads/tktest.zip
                          >
                          > Again, my apologies.
                          > Mike
                          >
                          > Max Skibinsky wrote:
                          >
                          > > Hi!
                          > >
                          > > Sorry if i'm missing something very obvious, but to make sure we
                          are on same page... Thats the
                          > > FCWTK.H in the zip file on your server:
                          > > -- file start --
                          > > // FCWTK.H
                          > > struct IDList
                          > > {
                          > > virtual void __stdcall DLDestroy(void) = 0;
                          > > virtual pENTREC __stdcall DLApnd(void* pENTREC) = 0;
                          > > virtual pENTREC __stdcall DLApndE(int,void* pENTREC) = 0;
                          > > virtual pENTREC __stdcall DLClone(void* pENTREC) = 0;
                          > > virtual void __stdcall DLErase(void* pENTREC) = 0;
                          > > virtual void __stdcall DLUnErase(void* pENTREC) = 0;
                          > > virtual pENTREC __stdcall DLReplace(void*,void*) = 0;
                          > > virtual void __stdcall DLDelete(void* pENTREC) = 0;
                          > > virtual pENTREC __stdcall DLResize(void* pENTREC,int) = 0;
                          > > virtual int __stdcall DLSave(void) = 0;
                          > > virtual int __stdcall DLLoad(void) = 0;
                          > > virtual int __stdcall DLScan(void) = 0;
                          > > virtual void __stdcall DLEmpty(void) = 0;
                          > > virtual void __stdcall DLRename(char*) = 0;
                          > > };
                          > > IDList* _stdcall CreateDList(char*,int);
                          > > -- end of file --
                          > >
                          > > if IDList::DLScan(void) is scanning function, how do i set the
                          callback? Thanks for the rest, just
                          > > what we needed!
                          > >
                          > > - Max
                          > >
                          > > ----- Original Message -----
                          > > From: Mike Riddle <mriddle@u...>
                          > > To: <cc2-dev-l@yahoogroups.com>
                          > > Sent: Saturday, February 03, 2001 9:48 PM
                          > > Subject: Re: [cc2-dev-l] FCW loader
                          > >
                          > > > The file FCWTK.H in the TKTEST directory (where you put the
                          FCWTK)
                          > > > has the prototype for DLScan and its callback.
                          > > >
                          > > > The various infoblock records (see the V6 or V7 xptoolkit files
                          for their
                          > > > definition) hold the fill style and line style data. Infoblocks
                          are entity type 0,
                          > > > and have a subtype IBType which identifies which one each
                          record is.
                          > > > This is defined in copy files for each infoblock. Note that
                          record type id
                          > > > numbers differ from V6 to V7.
                          > > >
                          > > > There is no color palette data saved with each V6 file. I have
                          uploaded the
                          > > > standard color table to www.fastcad.com/downloads/palette.cpy.
                          V7
                          > > > does contain a copy in the CMAPIB Infoblock (entity type 0)
                          record.
                          > > >
                          > > > Mike
                          > > >
                          > > > Max Skibinsky wrote:
                          > > >
                          > > > > Few questions. How do i scan/access entities in loaded file?
                          IDList::DLScan(void) has no
                          > > parameters
                          > > > > to put callback in... Also, how you would recomend to access
                          FCW file color table (RGB vals),
                          > > > > linestyle table and layer name <-> id table? Other then that
                          IDList methods are quite clear,
                          > > thanks
                          > > > > again!
                          > > > >
                          > > > > - Max
                          > > > >
                          > > > > --- In cc2-dev-l@y..., Mike Riddle <mriddle@u...> wrote:
                          > > > > > Hi - There is a prototype toolkit for directly reading FCW
                          files from
                          > > > > > standalone (non-XP) C programs available in the file:
                          > > > > >
                          > > > > > www.fastcad.com/downloads/tktest.zip
                          > > > >
                          > > > >
                          > > > > To Post a message, send it to: cc2-dev-l@e...
                          > > > > To Unsubscribe, send a blank message to: cc2-dev-l-
                          unsubscribe@e...
                          > > >
                          > > >
                          > > >
                          > > > To Post a message, send it to: cc2-dev-l@e...
                          > > > To Unsubscribe, send a blank message to: cc2-dev-l-
                          unsubscribe@e...
                          > > >
                          > >
                          > >
                          > > To Post a message, send it to: cc2-dev-l@e...
                          > > To Unsubscribe, send a blank message to: cc2-dev-l-
                          unsubscribe@e...
                        Your message has been successfully submitted and would be delivered to recipients shortly.