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

Re: [cc2-dev-l] using INSSDEF to add a multi-layered symbol to a drawing

Expand Messages
  • Peter Olsson
    The INSSDEF command does not do any layer translation. The INSSDEF command will not match the layers by name between the imported and the current one. It just
    Message 1 of 5 , Jan 8, 2002
    • 0 Attachment
      The INSSDEF command does not do any layer translation. The INSSDEF command
      will not match the layers by name between the imported and the current one.
      It just uses the sane numbers.

      Peter


      Background info (I'm copy from another source so you might as well get the
      rest of it):

      Each layer in a drawing is assigned an ID number. This number is looked up
      in a table
      whenever the layer name is needed. The list text window will show this ID as
      well as the layer name.

      The workaround is to start with the actual symbol file to create your
      template. Load the FSC file, and delete everything (purge unused symbols a
      few times). You now have the same layer names witrh the correct ID's. Now
      insert your old template as a part (using the PART command).

      ----- Original Message -----
      From: "Christopher Golden" <goldencd@...>
      To: <cc2-dev-l@yahoogroups.com>
      Sent: Tuesday, January 08, 2002 5:30 PM
      Subject: [cc2-dev-l] using INSSDEF to add a multi-layered symbol to a
      drawing


      > One of the users of Mappa Harnica has pointed out to me that
      > the INSSDEF command, when used to insert symbol definitions
      > that contain entities on multiple layers (e.g. the City De-
      > signer 2 building symbols), inserts the symbols with all
      > their component entities placed on the MERGE layer. From my
      > own testing, this seems to be the case even if I've modified
      > the map into which the symbols are to be inserted to include
      > all the layers that the symbols use.
      >
      > So in other words, if you use INSSDEF to insert the symdefs
      > contained in the CD2 "Classic.fsc" buildings catalog into a
      > drawing based upon a Mappa Harnica template, the symdefs'
      > component entities all get switched to the MERGE layer. It
      > does not seem to matter whether or not the layers used by
      > the symdefs are already present in the drawing or not; the
      > entities still all end up on the MERGE layer.
      >
      > Interestingly, this is *not* the case if INSSDEF is used to
      > insert the same symdefs into a CD2-template-based drawing.
      > In that case, the symdefs' component entities all remain on
      > the correct layers.
      >
      > Clearly, there's a reason for this behavior that I'm not
      > understanding. I've double-checked to make sure that the
      > various "STRUCTURES (xxxx)" layers that the symdefs in ques-
      > tion use are present in the drawing based upon the Mappa
      > Harnica template before I use INSSDEF, taking special care
      > to spell the layer names correctly. ;-)
      >
      > Does anyone have an idea why this would be happening?
      >
      > Thanks!
      > Christopher Golden
      > goldencd@...
      >
    • Christopher Golden
      ... Okay, that makes sense. In fact, as often happens, it seems obvious once I ve been told. ;-) Any chance that version 7 will use named layers, instead of
      Message 2 of 5 , Jan 8, 2002
      • 0 Attachment
        Peter Olsson wrote:

        > The INSSDEF command does not do any layer translation. The INSSDEF command
        > will not match the layers by name between the imported and the current one.
        > It just uses the sane numbers.

        Okay, that makes sense. In fact, as often happens, it seems
        obvious once I've been told. ;-)

        Any chance that version 7 will use named layers, instead of
        numbered ones? That way, this wouldn't happen.

        Thanks!
        Christopher Golden
        goldencd@...
      • Mike Riddle
        Layers are in fact, named. Its just that we don t want to repeat the text name with every entity in the drawing. So Layers and other named properties (line &
        Message 3 of 5 , Jan 8, 2002
        • 0 Attachment
          Layers are in fact, named. Its just that we don't want to repeat the text name
          with every
          entity in the drawing. So Layers and other named properties (line & fill styles,
          etc.) all
          use an Infoblock record to hold the actual definitions, and a "cookie" to index
          into this
          record when using the actual information. Its a space saving device. Whenever you

          merge drawings, you should in fact merge all property ids.

          Christopher Golden wrote:

          > Peter Olsson wrote:
          >
          > > The INSSDEF command does not do any layer translation. The INSSDEF command
          > > will not match the layers by name between the imported and the current one.
          > > It just uses the sane numbers.
          >
          > Okay, that makes sense. In fact, as often happens, it seems
          > obvious once I've been told. ;-)
          >
          > Any chance that version 7 will use named layers, instead of
          > numbered ones? That way, this wouldn't happen.
          >
          > Thanks!
          > Christopher Golden
          > goldencd@...
          >
          >
          > To Post a message, send it to: cc2-dev-l@...
          > To Unsubscribe, send a blank message to: cc2-dev-l-unsubscribe@...
          >
          > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
        • Christopher Golden
          ... Right, that makes sense. Admittedly, saving the text string with every entity would bloat the drawing sizes quite a bit. This also explains why the CD2
          Message 4 of 5 , Jan 8, 2002
          • 0 Attachment
            Mike Riddle wrote:

            > Layers are in fact, named. Its just that we don't want to
            > repeat the text name with every entity in the drawing. So
            > Layers and other named properties (line & fill styles, etc.)
            > all use an Infoblock record to hold the actual definitions,
            > and a "cookie" to index into this record when using the
            > actual information. Its a space saving device. Whenever you
            > merge drawings, you should in fact merge all property ids.

            Right, that makes sense. Admittedly, saving the text string
            with every entity would bloat the drawing sizes quite a bit.

            This also explains why the CD2 building catalog, when its
            contents are inserted into a CD2 template via INSSDEF, ends
            up with the symdefs' component entities on the correct lay-
            ers: Most probably, the same basic template was used for
            the catalog and the template.

            So, it sounds like the way that INSSDEF *should* work is to
            first compare the info blocks of the symbol catalog and the
            drawing, add any layers that are missing, and then change
            the layer cookies for each of the entities in the symdefs
            to match the values of the layers with the same names in the
            drawing.

            Come to think of it, INSSDEF (and other commands that merge
            drawings, as you said) should do this not just with layer-
            related info blocks, but with line styles, fill styles, etc.

            It would be quite nice if XP developers had the two func-
            tions detailed below at their disposal. Assume for the fol-
            lowing that drawing 2 is being merged into drawing 1:

            The first would, given two info blocks (one from each draw-
            ing), modify drawing 1's info block to include the values
            found in drawing 2's info block.

            The second would, given drawing 2's info block, the modi-
            fied info block that is created by the first function, and
            an entity, map the entity's properties from cookie values
            relevant to drawing 2 to values that work with drawing 1's
            modified info block.

            Is this something that could, or is likely to be, included
            in a subsequent release of CC2 and the XP developer's kit?
            I would certainly make use of it, and I suspect others
            would as well. (Or are they already available, and I'm
            just missing them?)

            Thanks again!
            Christopher Golden
            goldencd@...
          Your message has been successfully submitted and would be delivered to recipients shortly.