Subject:
|
Re: DAT format question
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Tue, 21 Sep 1999 22:59:46 GMT
|
Viewed:
|
458 times
|
| |
|
|
My original plans called for my CAD package to distinguish among the various
kinds of DAT file. This would allow the program to know when it was
appropriate to enable certain editing features. For example, it shouldn't
allow the user to add primitives directly to a model, or drop a part into a
primitive file--since each type of file (model, part, primitive) should only
be able to reference or contain objects of equal or lesser significance.
Also, the color selector would only display codes 16 and 24 when editing a
part or primitive, but allow any color for a part reference in a model or
subassembly (or, at least, something along those lines). In other words,
the user's ability to manipulate an object should be restricted to only
those actions that are in context for that object.
However, it seems that any type of file can be stored in any of the usual
suite of directories, and the program is supposed to allow this to be
compatible with the other CAD packages. This means that the parser will
have to be able to somehow analyze the contents of a file to determine what
kind of object it contains. I think it's unfortunate that James Jessiman
didn't assign different extensions to each object type...like .prj for a
project (model), .prt for a part, and .pri for a primitive (they could
easily all have the same internal format--the extension would only be an aid
in identifying the contents).
I think it's too much of a kludge to make the parser into a two-pass loop,
and try to reverse-engineer all the references...but I'm at a loss to think
of a better way.
The only other alternative I can think of would to have sub-menus on the
File/Open and File/New menus, one for each file type. Then it would be up
to the user to tell the program what type of file he was about to work with.
Thoughts?
-Gary
|
|
Message has 4 Replies:
 | | Re: DAT format question
|
| (...) I don't see that as being that big a deal, really. And if you could have some kind of button on a toolbar for each of them, all the better. (25 years ago, 21-Sep-99, to lugnet.cad.dev)
| | | Re: DAT format question
|
| Gary Williams wrote in message ... (...) with. Doh', this wouldn't be a complete solution, either. If the user opens a model, I'd still have to determine which external references in it are parts and which are embedded models/subassemblies. And if (...) (25 years ago, 21-Sep-99, to lugnet.cad.dev)
| | | Re: DAT format question
|
| (...) Why not? I've done this when a part didn't exist (I used a box.dat for the center of the 1x2x2 shock absorber) (...) Part developers often use different colors to make sure shapes are matching up correctly. Also, atterned parts and some other (...) (25 years ago, 22-Sep-99, to lugnet.cad.dev)
| | | Re: DAT format question
|
| (...) For new files, LDAO allows the user to specify the type of the file, separate from its location. The type information is written to the file as part of the header lines. When a file is loaded, LDAO looks for the typing information. If the file (...) (25 years ago, 22-Sep-99, to lugnet.cad.dev)
|
Message is in Reply To:
| | DAT format question
|
| Hello, I know that models can contain subassemblies (if MPD format), and primitives can contain subprimitives, but can parts contain subparts? I'm finalizing the object hierarchy for my Lego CAD program and need to know whether I should support this (...) (25 years ago, 19-Sep-99, to lugnet.cad.dev)
|
27 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
