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

Re: [cc2-dev-l] Appending SYMDEFs and SYMREFs to drawing list

Expand Messages
  • L. Lee Saunders
    Hi Chris; I ll leave the memory questions for Peter, though in digging into the file format (which is just the entity database saved to a file) that all
    Message 1 of 3 , Apr 26, 2000
    • 0 Attachment
      Hi Chris;

      <SNIP> I'll leave the memory questions for Peter, though in digging into the
      file format (which is just the entity database saved to a file) that all
      entites are saved at the end of the file. Since you have to have a SYMDEF
      before you have a SYMREF for that symbol, they are already in the correct
      order. If you replace a SYMDEF with a new one, move it to the front of the
      database.

      >Second, when I actually insert a SYMREF, I'm not sure what values
      >I should fill in for the various fields. The "Low" and "Hi" points
      >are obvious enough, but what is the proper function or functions to
      >be used to calculate the low and high extents of the symbol? The
      >"SName" is obviously the name of the associated SYMDEF. But what is
      >the "DefAdr" exactly -- is it a pointer to the associated SYMDEF's
      >entity record? And finally, how do I calculate the contents of the
      >"TMat" transformation matrix? I see functions to use symbol trans-
      >formation matrices, but no way jumps out at me to actually build up
      >the matrices themselves.

      I had to ask Peter the first time I did this as well. Here is the code along
      with some comments.

      //First we set a variable to hold the pointer to the symdef we are
      //looking for.
      pENTREC pSymDef;

      // This function searches the dB to find a symdef with the name NAME
      DWORD FindSymDef(hDLIST hDList, pENTREC pEntRec, char *Name, PARM parm2)
      {
      if ((pEntRec->CStuff.EType==ET_SYMDEF) && lstrcmp(Name,
      pEntRec->SymDef.SName)==0)
      {
      pSymDef=pEntRec;
      return 1;
      }
      return 0;
      }

      //Here we declare a variable to be a new symref
      SYMREF SymRef={sizeof(SYMREF), ET_SYMREF};

      //Here we call the above function. We've loaded SymbolName with
      //the name of the symdef we are looking for.
      if(DLScan(NULL, FindSymDef, DLS_Std, &SymbolName, NULL))
      {
      //Set our new symref to the current CStuff
      GetCStuff(&SymRef.CStuff);

      //Set our symref's low and hi the the symdef's low and hi
      SymRef.Low=pSymDef->SymDef.Low;
      SymRef.Hi=pSymDef->SymDef.Hi;

      //Here we create a transform matrix. See bottom of page 69.
      CTMI2();
      //Here we set the angle of the symref into the matrix
      CTMR2(TanAngle);
      //Here we set the size of the symref into the matrix
      //note that I set them to the same size - they do not need to
      //be the same.
      CTMS2(Size, Size);
      //Lastly we set the location of the symref. You always do this
      //last because all transformations take place in relation to
      //0,0 so if you moved it first then rotated it, it will rotate
      //about 0,0
      CTMT2(Pt.x, Pt.y);

      //According to Peter you need to TranP2 to tell CC2 that this
      //symref exists to that when we zoom extends it will know to
      //show the new symref.
      _TranP2((GPOINT2 *)&SymRef.Low);
      _TranP2((GPOINT2 *)&SymRef.Hi);

      //I'm fairly sure it applies the matrix to the symref
      STSymTM(&SymRef.TMat);

      //Here we connect the Symref to the Symdef
      SymRef.DefAdr=&pSymDef->SymDef;

      //Set the name of the symref to equal the symdef
      lstrcpy(SymRef.SName, pSymDef->SymDef.SName);

      //Lets Draw It!!!
      EDraw(DLApnd(NULL, (pENTREC)&SymRef));
      }

      I hope this helps.

      Lee
      ________________________________________________________________________
      Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
    • Peter Olsson
      Hi Chris, ... SymDefs may be placed anywhere in the main drawing list (i.e. it may not be placed in a sublist such ass groups or sheets). For speed reasons
      Message 2 of 3 , Apr 26, 2000
      • 0 Attachment
        Hi Chris,

        >- Is it really okay to add SYMDEFs anywhere within a drawing?
        > The somewhat incomplete XPDOC.PDF tutorial file that comes
        > with the XP development toolkit implies that symbol defini-
        > tions go at the beginning of a drawing list; thus, is it a
        > bad idea to append a new SYMDEF to the end of a drawing list?

        SymDefs may be placed anywhere in the main drawing list (i.e. it may not be placed in a sublist such ass groups or sheets). For speed reasons they should be placed at the beginning, but this is not essential in any way to the functionality. Also since all SymRefs stores a cached address to the SymDef the lookup will only take place each time the database is moved in memory (after Load and Save etc.)

        >- Presumably, before copying a SYMDEF into a drawing list, I
        > should check and see if a SYMDEF by the same name already
        > exists in the target list. If it does, I can mark the old
        > one as deleted, presumably, prior to adding the new one.
        > But is this safe? I notice that SYMREF entities contain as
        > part of their structure the variable "DefAdr", which is
        > noted to be the runtime address of the associated SYMDEF.
        > So, if I mark the old SYMDEF as deleted, do I need to go
        > through all the SYMREFs in the drawing that point to this
        > deleted SYMDEF and change their DefAdr variables to point
        > to the replacement SYMDEF?

        I also believe you have to replace all references from the SymRefs as well. One solution here would be to leave the SymDef entity as it is and replace its SubList. In order not to move the entity you will have to DLDelete all entities in the sublist and then add the new ones here. If you don't do this use DLMove to place the SymDef in the correct order (to not mess up symbol catalog orders etc). Also remember the extents values in each symref if you care about the zoom extents to work properly.

        >- Peter also mentioned that the info blocks for the symbol
        > catalog and the main drawing are not merged, and thus (for
        > example) if the symbol catalog's info block defines fill
        > style 1 as a solid fill and the drawing's info block defines
        > fill style 1 as hollow, the SYMDEF may not look right in the
        > drawing. Is there any way to merge the info blocks? I pre-
        > sume that there is, given that it is possible to insert
        > drawings into other drawings and so forth. Or must it be
        > done by hand?

        There is not FastCAD SVC for this so you will have to write your own. For each info block (like fill style) you will have to check every style in the imported drawing for the corresponding number in the main drawing (If it doesn't exist it has to be added). Then you'll have to change the fill style numbers in the imported drawing to the ones looked up in the main drawing.

        This is quite some work and my tip is to avoid it if you can. I'm trying to get Mike Riddle (author of FastCAD) to include a merge info-blocks SVC in version 7.


        I hope the above stuff made sense.

        Peter, who have been spending the last 24 hours (except for 4 hours of sleep) flying hot-air balloons (not all the time though).
      • Christopher Golden
        ... Hmm, interesting! I m starting to think of taking the easy way out on this: When adding a symbol catalog s symbols to a drawing, skip adding any symbols
        Message 3 of 3 , Apr 26, 2000
        • 0 Attachment
          Peter Olsson wrote:

          > SymDefs may be placed anywhere in the main drawing list (i.e.
          > it may not be placed in a sublist such ass groups or sheets).
          > For speed reasons they should be placed at the beginning, but
          > this is not essential in any way to the functionality. Also
          > since all SymRefs stores a cached address to the SymDef the
          > lookup will only take place each time the database is moved
          > in memory (after Load and Save etc.)

          Hmm, interesting! I'm starting to think of taking the easy
          way out on this: When adding a symbol catalog's symbols to
          a drawing, skip adding any symbols that have identical names
          to symbol definitions already within the drawing. This way
          I don't have to replace old symbols with new ones.

          > I also believe you have to replace all references from the
          > SymRefs as well. One solution here would be to leave the
          > SymDef entity as it is and replace its SubList. In order not
          > to move the entity you will have to DLDelete all entities in
          > the sublist and then add the new ones here. If you don't do
          > this use DLMove to place the SymDef in the correct order (to
          > not mess up symbol catalog orders etc). Also remember the
          > extents values in each symref if you care about the zoom
          > extents to work properly.

          I'll keep this in mind if I don't go at this the easy way.
          :-) Not that this isn't quite possible to do, just that
          it's harder than sliding out of it.

          > There is not FastCAD SVC for this so you will have to write
          > your own. For each info block (like fill style) you will
          > have to check every style in the imported drawing for the
          > corresponding number in the main drawing (If it doesn't
          > exist it has to be added). Then you'll have to change the
          > fill style numbers in the imported drawing to the ones
          > looked up in the main drawing.

          Ack!

          > This is quite some work and my tip is to avoid it if you
          > can. I'm trying to get Mike Riddle (author of FastCAD) to
          > include a merge info-blocks SVC in version 7.

          I agree; I plan on avoiding it. As with the symbol-
          replacement issue above, merging the info blocks is not
          strictly necessary for the XP I'm trying to create. The
          symbols that are to be used with my command are all quite
          simple, with solid and hollow fills only. I was just
          trying to be thorough, but perhaps I'll wait for version
          7 and see if FastCAD will do it for me. :-)

          > I hope the above stuff made sense.

          Very much so, thanks again!

          > Peter, who have been spending the last 24 hours (except
          > for 4 hours of sleep) flying hot-air balloons (not all the
          > time though).

          Something I've never done and hope to do someday... Sounds
          like a lot of fun!

          Take care,
          Christopher Golden
          golden@...
        Your message has been successfully submitted and would be delivered to recipients shortly.