Subject:
|
Re: DAT format question
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Wed, 22 Sep 1999 03:08:22 GMT
|
Viewed:
|
482 times
|
| |
|
|
Bram Lambrecht wrote in message <19990921.200045.5095.4.braml@juno.com>...
> "Gary Williams" <graywolf@pcpros.net> writes:
> > For example, it shouldn't allow the user to add primitives directly
> > to a model,
>
> 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)
My experience has been that as flexibility increases, complexity increases.
I'm usually quite anal about coding objects to always behave in a very
structured, predictable pattern.
Should I also allow inserting a free-floating polygon or line anywhere on a
model? Or would geometric primitives (polygons, lines, optional lines) not
be allowed unless you opened a file as a part/primitive?
Here's one scenario where it's bad to allow having primitives right on
models. Suppose you have a model open. You click somewhere on the top of a
stud on a brick. The program won't know whether you intended to select that
particular polygon, the primitive that contains the polygon, or the brick
that contains the primitive.
Or would the selected object always be something that was added directly to
the root model?
If you clicked on a stud on a brick on a subassembly of a model, would the
subassembly become the currently-selected object?
If you opened a brick as a part, then clicking on a polygon on the stud
could make the stud the currently-selected object...while in the primitive
editor, that polygon could become the currently-selected object. Always
stopping one level beneath the outermost object seems like a rule that would
always suffice.
> > Also, the color selector would only display codes 16 and 24 when
> > editing a part or primitive,
>
> Part developers often use different colors to make sure shapes are
> matching up correctly. Also, atterned parts and some other parts
> (electric parts) require specific colors other than 16 and 24.
I meant that as an example of how some controls could limit themselves. But
your comment is noted.
> > but allow any color for a part reference in a model or subassembly (or,
> at >least, something along those lines).
>
> Make sure you allow parts of models to be color 16. That helps in
> playing with color schemes.
> > 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.
>
> I would try to limit the amount of restrictions as much as possible.
If all DAT files are treated equally, this could create confusion with new
users, by not being able to have the most-likely options at a given time
displayed more prominently.
> > 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.
>
> Is this really necessary? After all, the format of all the types of
> files is the same. (parts reference primitives as if they were parts,
> models use submodels as if they were parts)
Not exactly the same. As I understand it, a model can have steps, but a
part and a primitive can't. Or at least it wouldn't make sense in those
applications.
> > 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.
>
> I think this would be best. Let the user choose which interface
> (primitive, part, model) (s)he wants to use.
Well, I'll experiment with collapsing my object class hierarchy and
simplifying it to have one universal object to represent models, parts, and
primitives. Maybe I did go overboard when I defined twenty classes...:)
-Gary
|
|
Message has 2 Replies:
 | | Re: DAT format question
|
| Gary Williams: (...) [...] (...) Then give the user a _choice_ of interface. (...) I would limit command types 2-5 to the "extended interface". (...) The selected object would of cause (imo) always be the level referred directly to by the root level (...) (25 years ago, 22-Sep-99, to lugnet.cad.dev)
| | | Re: DAT format question
|
| (...) Complexity also increases as over-specification increases. (...) Yes, polygons and lines should be allowed. Maybe that should be on the advanced interface, but it should be allowed. (...) Yes. (...) Exactly. And if you right-click an object, (...) (25 years ago, 22-Sep-99, to lugnet.cad.dev)
|
Message is in Reply To:
| | 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)
|
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
|
|
|
|
