The DataCAD Developer Network (DDN) is an online resource for information and support for DCAL® (DataCAD Applications Language) developers as well as anyone interested in creating fonts, toolbars, hatch patterns, or linetypes for use in DataCAD.

Moderator: pjdixit

#71370 by dhs
Sun Apr 30, 2017 2:49 am
I've found an old post from about a decade ago stating that 'The current DCAL does not allow associative hatch'. .... But that won't stop me tying! I suspect that the hatch might be set up with a series of entity attributes, or maybe it's some undocumented fields in the entity definition. This is not a must have for me, but it would be nice. Does any body have any advice regarding this (i.e. am I wasting my time even looking, or can somebody point me in the right direction) ?
#71381 by dhs
Mon May 01, 2017 9:10 pm
After a bit of time examining objects and their attributes I came to the conclusion that it is not easily possible to create an associative hatch by using DCAL to add attributes to a polyline entity: It may be possible to use a variant record to set up the string for the HATCHDEF attribute (which is atr_str, but appears to used to store scale, angle, origin etc in a binary format), but the HATCHSCANLIN attribute is of type 8 which is not documented in the DCAL manual. Even if you did manage to reverse engineer the required settings, there would always the the possibility of a change in a future version of DataCAD which made the macro incompatible (I'd be particularly nervous about the string used to store binary data in this respect).

It is possible to create an associative hatch by using ent_copy to copy an existing hatch and then updating/adding/deleting polyverts of the new entity to define the new area to be hatched.
Using this method a macro could create associative hatches, but only by getting the user to identify an existing hatch with the required attributes ... this technique may be useful in some circumstances.

My biggest issue was that hatches created with hatch_mode had snapping points for every hatch line: I did find a solution to that, but it is a slightly different topic to this so I will post my findings in that regard in a new thread.
#71511 by dhs
Fri May 19, 2017 7:18 pm
I couldn't leave this alone....
Decided I wanted to use a macro to create solid fill, and have managed to reverse engineer the required attribute (which is a string attributed named 'DC_FILL' but containing binary data).

The following macro can be used to add solid fill (what I have deduced about the DC_FILL attribute is shown in the filldef record).

Any comments about the advisability of doing this ? (is the definition of the DC_FILL attribute likely to change in future releases?).
Can anybody add anything further to this? (perhaps somebody knows what the 'dunno' fields are used for?)

Code: Select allPROGRAM TestFill;

      filldef = RECORD
         dunno1   : integer;   ! seems to be always 272
         dunno2   : integer;   ! seems to be always 0
         fillclr   : integer;   ! clrnum x 256,  +255 if entity clr,  (wraps to -ve over clr127)
         entclr   : integer;   ! -1 to fill with entity clr, else 0
         filltyp   : integer;   ! 0..6 multiplied by 256
         ptnclr   : integer;   ! clrnum x 256

      atrstr = RECORD
         a : integer;
         CASE integer of
            0 : (s : str80);
            1 : (f : filldef);

   res      : integer;
   mode   : mode_type;
   key      : integer;
   ent      : entity;
   addr   : entaddr;
   aAddr : atraddr;
   atr      : attrib;
   a         : atrstr;
   i         : integer;
   clr      : integer;
   fd      : atrstr;

         res := getmode ('to fill', mode, key);
         if res = res_normal then
            addr := ent_first (mode);
            WHILE ent_get (ent, addr) DO
               getclr (clr);
               atr_init (atr, atr_str);
               fd.f.dunno1 := 272;
               fd.f.dunno2 := 0;
               fd.f.fillclr := clr*256;
               fd.f.entclr := 0;
               fd.f.filltyp := 0;
               fd.f.ptnclr := 256;   ! value doesn't matter for solid fill?
               atr.str := fd.s;
      := 'DC_FILL';
               atr_add2ent (ent, atr);
               ent_draw (ent, drmode_white);
               addr := ent_next (ent, mode);
      until res <> res_normal;
   END TestFill.
#71536 by David A. Giesselman
Mon May 22, 2017 3:06 pm

That's close, but it's a bit more like this:

Code: Select all   TYPE
      filldef = record
         Version : integer; ! Should be 1
         Fill_color : longint; ! Entity color if < 0
         Fill_pattern : longint; ! 0-6
         Pattern_color : longint; ! Entity color if < 0

#71554 by dhs
Tue May 23, 2017 2:27 pm
... except your record definition does not seem to work in DCAL.

just clutching at straws here, but perhaps DCAL aligns longints with double word boundaries or something like that? At any rate when I use your definition it doesn't seem to align with the actual.

I'm sticking with what I had in my previous post for now: it works, and I can understand how it relates to your definition (although I don't understand why I am seeing 272 as the version).

Who is online

Users browsing this forum: No registered users and 2 guests

About DataCAD Forum

The DataCAD Forum is a FREE online community we provide to enhance your experience with DataCAD.

We hope you'll visit often to get answers, share ideas, and interact with other DataCAD users around the world.


Software for AEC Professionals Since 1984