readme.txt

一个比较完整的读写dxf文件的DELPHI程序

transformation.

NB : All matrices are created when the entity is created, then
stored for use when necessary. Usually they're just nil.

NB : the function update_transformations(...) in DXF_Utils uses
a temporoary global matrix to store results, we need this to
save allocating space for new matrices every time we multiply two.
(Since I wanted to pass pointers for efficiency, I couldn't make
the update transformations routine return a record structure)
Now all entities overwrite this every time they need to, but
because INSERTs & BLOCKs can be nested many levels deep, we must
use a stack allocated matrix in those draw routines to prevent
us losing a previous one.

Phew! - I'm glad I've finished that explanation.

Another BLOCK comment
=====================
The drawing routines, simply draw all the selected entity lists.
The BLOCKS are just like any other entity, so they get drawn too.
I've added a checkbox to stop them being selected, because it's
annoying when they keep appearing randomly all over the place.
If you want to see them or save them with the file, you must
uncheck the checkbox and select the BLOCK list.

Saving DXF files
================
If you load a file, then save it, you won't get an exact copy.
Any information that isn't read by my code is lost, and in
addition, to make the BLOCK referencing easier, I put all BLOCKs
in layer '0'. (It says they should always be there in the docs,
but I have found a couple of files with BLOCKs in any layer).
Be warned that because all BLOCKs get placed in layer '0', when 
you load multiple DXFs, the BLOCKs will be merged, so when you
save data, you may end up with more than you wanted.
YOU MUST SELECT THE BLOCKS LIST WHEN SAVING DATA.
The code treats them specially, but they must still be included
when saving.

Mouse
=====
The mouse tracking, does not exactly follow the x,y coords of the
mouse, but instead looks for the nearest vertex in the display
list(s). It then shows this point. The extended info shows the
full details of the entity that the point belongs to. The code
does this in two passes, it asks each entity list for the nearest
point (using squared distance to save time), and then afterwards
gets the info it needs. (ARCs and CIRCLEs use the centre of the
object geometrically speaking). The mouse tracking can take a
noticeable amount of time with very large datasets, so I've used
a timer linked to the mousemove, which should allow regular
updates, without slowing everything down too much.
NB : Ver 2.1 : I've now added a point_in_object(2D) test for
polygons & circles. (I wanted the nearest point test because lots
of my data is lines and points).
NB : Ver 3.0 : Now that 'true' 3D objects are implemented, the
coordinates of the mouse may not correspond to the coordinates
of the object. This means the mouse tracking fails. This doesn't
bother me, because my data is essentially 2D, if you must
interrogate objects then you'll need to get the tranformed vertex
coordinates and check these.
Also, since BLOCKs are inserted with a single point, one would
need to search the transformed BLOCK coordinates and I've not
implemented this.

Polyline attributes
===================
Inside the Polyline_ entity I have allocated space for some
attributes. These are different from the ATTRIB entity that can
be associated with INSERTs, I've allocated this space because I
need to tag my polylines with flags to indicate wall/roof/tree
types etc. and also material properties. You can safely remove
these extra attribute flags, but they may prove to be useful for
your own purposes.

Naming conventions
==================
If you add your own entities, care should be taken when naming
them - I've used a virtual method: proper_name - to return the DXF
entity name that should be used when writing data to DXF files. At
the moment it simply capitalizes the class name and strips off the
underscore. (e.g. Polyline_ becomes POLYLINE which is the correct
DXF name)

The reason that I called my entities line_, polyline_, point_ etc.
is to avoid name conflicts with reserved words and other component
method/member names etc. There is no reason why an alternative
naming convention couldn't be used.

NB : Ver 3.0 : some new variants of Polylines override the
proper_name function for obvious reasons.

Comments
========
I have put very few comments in the code, since most of it is
pretty straightforward, but the 3D BLOCK transformations and
Arbitrary axis algorithm are a little complicated so I've tried
to explain what's going on.

Bugs that I do know about
=========================
When tiny (or zoomed out) ARC's are plotted, The endpoints may be
too close together and not separated by more than one pixel. The
Windows ARC routine fails and draws an ARC that is nearly a
complete cirle, rather than a tiny segment. I don't care, because
there are no ARC's in my datasets.

If you copytoclipboard, the machine may GPF, this appears to be
related to the ARCs problem above, Windows NT is OK, but win95 is
duff. (The problem is also caused by integer overflow when
calculating coordinates)

ARCs and CIRCLEs get plotted incorrectly in 3D, this is simply
because the insertion point gets transformed, but I've not
bothered turning them into ellipses when viewed side on. This
is particularly noticable in the 3d-craft.dxf dataset.

If you have polylines with a lot (>1024) points you may get
troubles, again NT is fine, and I've set a variable
Maxpointsperpolyline or something like that, that you can adjust
if you do have problems.

Files with lots of ATTRIBs per insert may cause problems, because
I've statically allocated space for 16 (I think), so you might
need to increase this, or use dynamic allocation. (My data files
only ever contain one ATTRIB per insert, so I've never had
problems)

If a file with no $EXTMAX, $EXTMIN data is read, the entities are
scanned to find the limits in (x,y & z), but the values may be
incorrect, the major source of this problem is BLOCKs, which can
be inserted at one place, but extend for a distance in any
direction from the insertion point. To correct this, you'd need
to get the transformed coordinates of all visible objects, which
would be fairly simple to do.

The warning messages such as 'Invalid header or no Layer
information' etc. are set to stay on the screen for a second or
so, to give you time to read them, but you may find this annoying,
but I've put the delay in, to ensure you know about it. All the
DXF files I get are OK, but I tested this code on a number of
downloaded mesh files when I added the 3DFACE entity, and many of
them just have an ENTITES section and nothing else, so they often
give the error. (eg skull.dxf)

When loading multiple DXF's, the layers simply get added together,
so file 1 may be titled 'somecrap.dxf' and file 2 may be
'morecrap.dxf', these will both become 'somecrap.dxf', it wouldn't
be hard to separate these files, but I've not implemented it here.
Multiple DXF's with wildly different (x,y) extents, may not load
well together.
In addition to this, the BLOCK tables get merged, and since I've
not added a facility for editing/deleting individual BLOCKs you
should be aware of this. If you had two files with BLOCKs of
the same name, you'd have trouble. It might be worth adding some
checks when loading if you think you'll encounter this problem.

Previously I thought that all DXF files had layer tables defined,
but I've recently come across some which don't, so I've allowed
all entities to be read, and if they contain an undefined layer
name, then a new layer is added. I didn't do this originally
because I thought if a file with an error in it was read, it'd
cause hundreds of dodgy layers to be created, but I decided this
precaution was unnecessary since you'd soon notice if the file
was flawed.

There are some entities this code doesn't handle, so I allow any
codes which are not read to be added to a list so that you can see
what's been missed out. Mostly you can simply ignore this, if you
pass a nil pointer instead of a valid stringlist, then it will not
bother storing this extra information.

Math.pas : If you have the desktop version of Delphi, rather than
the developer version, you probably haven't got math.pas.
I can't include it with this code because it's copyright Borland,
all you need to do it remove any references to uses...,math, and
compile. You'll get a few errors, mostly for DegToRad etc, simply
write a couple of functions to do these yourself.

Unfinished bits
===============
I haven't quite finished the BYLAYER and BYBLOCK colour control,
it's a pain and I wanted to get this version released and forget
about it for a while. Also, some entities come out looking a 
little different from what they're supposed to (eg SOLIDs), I 
think some of the specs may have changed from AutoCAD versions 
prior to release 13, which is the specs I based this code upon.
I've deliberatly not included a 3D view, because I don't need it.
Some of the functions like mouse tracking and extent checking 
don't take into account the BLOCK positions (the highlight
routine doesn't show them as selected either).
There are lots of other little glitches that are left to the 
interested programmer to find.

Version History
===============

3.0 (July 1997)
---------------
Added support for BLOCKs (big addition hence version 3.0 jump)
Arbitrary Axis Algorithm implemented for _ALL_ 2D objects with
  arbitrary alignment in 3D space, and complex 3D objects made
  up from BLOCKs.
ATTDEF supported (in BLOCKs section).
POLYLINE (polyface mesh - vertex array + face array) supported.
POLYLINE (polygon mesh - N*M array) supported.
Improved Zoombox with draggable rectangle and better scrollbars
  (courtesy of Dani Andres Izquierdo).
SOLID supported
TEXT alignment added for simple horizontal justification.
Modified layer error check so that new layers are always created.
Minor modifications throughout to incorporate new funcionality.
Aspect ratio code removed because it was annoying.

2.1 (Apr 1997)
--------------
Unix LF (as opposed to PC, CR/LF) on EOL supported on read.
Files with no header, no layers, no tables read OK (warning
 displayed).
3DFACE supported.
Multiple DXF files can be loaded, (they will be merged).
Point in polygon (or other closed object) mouse track test added.
Modified read routines to make some simpler.

2.0 (Mar 1997)
--------------
Completely Object Oriented.
Much improved read structure.
Write DXF added.
Better Zoombox and mouse tracking.
ATTRIB,TEXT,CIRCLE,ARC supported.
All source included.

1.0 (Sep 1996)
--------------
Working DXF code, very tatty, not all source included.
POINT, INSERT, POLYLINE, LINE supported


Site to find latest version
---------------------------
http://rcru1.te.rl.ac.uk/~jab/dxf