Dimension Extension Linetype

To each his own, I guess, but we use a highly-customized set of one-click
tablet commands for dimensioning (among other things). Instead of just
DIMLINEAR, we have PT2PT, PT2CL, CL2PT, CL2CL, CONT2PT, and CONT2CL, among
others. The additional overrides could be easily incorporated, and would buy
us a *lot* in increased productivity.
___

place the line than to run around overriding this one and suppressing that
one and "oops updated the wrong one", etc.

 

But what have you gained, production-wise? To me it just seems easier to
place the line than to run around overriding this one and suppressing that
one and "oops updated the wrong one", etc.

Could be -- different strokes, etc. Granted, this isn't a large item for us
in the grand scheme of things.

Like Paul, I have a few customizations that deal with dimensioning things we
routinely encounter. In my case, things like a one-click
extension-suppressor (so you don't have to guess whether it's extension #1
or #2). If the variable's there you can automate it and make the process
transparent, and gain a smidgen of productivity. Sometimes it's convenient
to have a predefined style you can match, sometimes an isolated override is
simpler. But on this item we lack the variable.

And again, I wouldn't necessarily deal with all centerlines in the same
manner. I certainly don't disagree that many times the simple low-tech
solution is the best way to go, even if it's not the most "pure"
conceptually.

 

and would buy us a *lot* in increased productivity.<

Not any mode that a few custom routines would do for you now. All our col grid lines are placed with a few strokes from a custom routine, as are centerlines for circular object.

 

There's one of those words thrown around these boards a lot that no one has bothered to define. What do you mean by "pure" conceptually? Is that like Microstation's "intuitive"?

 

What do you mean by "pure" conceptually? Is that like Microstation's
"intuitive"?

That's a scary comparison! I dunno, maybe a bad word choice. In principle it
would seem "cleaner" or more "elegant" to have more potential control over
extension lines, to avoid having to include separate unassociative things in
your dimensions. Whether it would be a measurable improvement in the real
world might depend in part on personal preferences.

Don't know what those other folks mean, but I guess I'd take "pure" to point
in the theoretical direction rather than the empirical. I didn't mean to
imply that purer was better. There's a lot to be said for "good enough."

 

Dear OLD-CADaver, you are, as usual, right that it takes as much work to edit the dimension as to draw a centerline. You asked what could be gained. If we could have on of the extension lines have a centerline linetype, then, the dimension could remain associative. We use dimension lines to locate toilets in restrooms. The dimension string might run from the wall to the toilet to the partition to the next toilet to the next partition, and so on. In such a case, every other extension line would be a centerline. As it is now, we draw centerlines from the toilets to the dimension location, then, dimension to the centerlines. It would be nicer if we could just move the toilet when desired and have the dimension update. Right now, we have to move the toilet and the centerline, and, verify that the dimension updates. All of this discussion is just in hope that AutoCAD will notice and future versions will appease us picky drafters out here. Read Ya Later -KLYPH

 

That's exactly the sort of thing we encounter in architectural plans too - a
mixed bag of centerlines and normal extensions all on one dimension string.
It's not a hugs issue, but having that linetype control as part od the
associative dim would eliminate one more messy little editing operation
(with associated chance of error).

 

Now you've hit on something that ADESK should spend some development time/money on. Maintaining DIMASSOC=2 associatively. Rather than extension line linetypes, give me a DIMASSOC=2 that works, that won't drop associatively for no apparent reason. As it stands now, even if you move the toilet with the dimension associated, you have to verify the dim didn't "forget" it's associatively.

Now, let's say it DID remember it's association. Moving 5 toilets and a centerline, doesn't seem like a great deal more work than moving 5 toilets. BTW, most of us want the centerline to continue past the extents of the toilet anyway, it wouldn't stop at the center of the tank insertion point.

I belabor this point, because this is the kind of wish point that gets a new version of AutoCAD released every 18 months. Everybody wants their own little pet feature incorporated into the program, then they want to complain that ADESK is pumping out new releases just to pad their pockets. You can't have it both ways.

I, for one, don't mind the incremental upgrades. If your little pet gets added, good for you, next time maybe mine will. There are things I think should get a higher priority, but oh well. In the mean time I plan on putting back $50 per seat per month in anticipation on the next release.

Got a little long-winded there, sorry 'bout that chief.

 

place the line than to run around overriding this one and suppressing that
one and "oops updated the wrong one", etc.

But what if you could right click on a particular extension line and have
all available linetypes (or an office standard list if Autodesk gets it
right) that you just apply to the selected extension? And I still want to
see conrol over what is dimensioned how in the style. I.e. the style knows
that when an extension line is tied to a Center or Quadrant you use the
Center linetype, otherwise use Continuous (all user/cad manager customizable
of course). In ADT the style would know that when dimensioning to the
midpoint of door & window objects, and insertion of column objects, you use
center linetype, otherwise Continuous. And you always have the option to
toggle special cases on and off. And I love the idea that a 100% coincident
extension line just knows to turn itself off. I spend way to much time just
doing that for my liking.
If done right, it could be a huge time saver. If done wrong no one will use
it and we keep putting in seperate lines, just like now.

Gordon

 

Everybody wants their own little pet feature incorporated

I'd like to get my hands on whoever thought that Properties needed changing
in 2004.

 

Curious - what don't you like about it?

 

BTW, I REALLY like the fact that I can once more enter mathematical
expression for real number values, such as: 1/3

I remember I couldn't do that with the 2002 Properties - though it could be
done in the old-OLD R14 Properties dialog.

So to whoever fixed that - sincerely - thanks a bunch!

Best regards,
David Kozina

 

Curious - what don't you like about it?

Mostly, big honking fonts with excess line spacing and fat section headers,
purely for decoration, with the effect that (by direct comparison) only
about half the information is available on screen without scrolling. Then
the little undersized scroll widget that you now have to use twice as much.
Then the removal of toggling between values by double-clicking, which was a
favorite among our users, especially for on/off type values.

I don't mind "cute" except when it interferes with legibility, like the new
bubble-licious style toolbars, or reduces access to information, like the
palettized properties command.

We didn't install 2002, but in 2000i properties, you can enter either
regular or irregular fractions exactly as in 2004, nothing changed there
that I can see.

 

er... aren't those WINDOWS controlled???

 

er... aren't those WINDOWS controlled???

No, because I ran 2000i and 2004 side by side in tiled windows to note the
differences I mentioned.

One has legible toolbars, the other doesn't. It's the graphic design of the
toolbars that differs, not their size. The 1 pixel height difference isn't
real obvious to me.

The comparison of the amount of information visible in Properties was based
on selecting the same complex entity in the same drawing file, open in both
versions, and putting both Properties side by side. Both versions have the
same text size in pulldowns and command line. 2004 has signficantly taller
text in Properties, at a wider line spacing, and I'm not aware of a user
setting that will independently control this. If there is one, I'll be a
happy camper.

The physical font height in both cases would be a function of screen
resolution and dot pitch, but on what I have, there are just about twice as
many lines of information visible in 2000i, and I wouldn't think that any
common monitor setting would significantly change that ratio.

Presumably I could go up one more click to maximize my monitor's resolution,
but that would render every other application, and all the rest of Acad,
illegibly small for me.

 

Speaking of making it better. Does anyone like the idea of cascading posts becoming one letter wide after a dozen replies? Or is it just me, as usual?

 

I didn't see this mentioned yet (and didn't catch it if it was):

I change the entire dimension to center linetype, turn off adjacent extension lines if necessary, then draw the rogue line over the dimension line instead. This keeps most of the associativity.

 

That's probably more cumbersome than just drawing a separate extension line;
and, besides, we very often need just *one* centerline extension line in a
particular dimension or series of dimensions.
___

extension lines if necessary, then draw the rogue line over the dimension
line instead. This keeps most of the associativity.

 

One option not yet mentioned. Skip the linetype as a relic of hand drafting,
and go to a dot for dimensions that are to center, with the slash or arrow
for dimensions to an edge. You could even create a little lisp to toggle
selected arrows between overrides and not.
I think this is especially workable for architects, because the truth is
every office has a different graphic standard (maybe every PA/Design team,
in some offices every darn drater) so establishing something less standard
but still workable is not just possible, but potentially a good thing.

Best,
Gordon