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

using INSSDEF to add a multi-layered symbol to a drawing

Expand Messages
  • Christopher Golden
    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
    Message 1 of 5 , Jan 8, 2002
    • 0 Attachment
      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@...
    • 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 2 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 3 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 4 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 5 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.