Topic: Superflatten.lsp and dimension extention defining points

[moom]

Hello all,

I've received a AutoCAD2007 drawing with a mix of objects drawn on the plain with Z=zero, and objects that were drawn while inadvertently a UCS was set with Z not equal to zero. I've run superflatten.lsp to resolve this, but I've found that it leaves most extention defining points of many dimensions outside the Z=0 plain. Some testing revealed that superflatten.lsp moves dimension to the Z=0 plain correctly when the entire dimension (extention defining points as well as dimension line defining point) where drawn in the same Z plane originally.
On the other hand, when the dimension has been drawn in such a way that the extension defining points and the dimension line defining point are on different Z plains originally, running superflatten results in that only the dimension line and extension lines are moved to the Z=0 plain, but the extension defining points just move over the same relative distance and are left floating above or under the Z=0 plain, with a Z-distance they originally had relative to the dimension line defining point.

I've attached an example of a dimension of which the extension defining points are not moved to Z=zero when while running superflatten.

I've examined superflatten. lsp and found that dimensions are processed by routine FlatDimension. Reading this section, I would expect that FlatDimension attempts to "flatten" each individual sub-object of a dimension separately, and I think that extension defining points are processed by the calls to either the `ExtLine1Point object or 'ExtLine1StartPoint object (and the matching "2" object respectively).

Based on my testing, I believe that the defect seems to be caused by (vlax-property-available-p obj 'ExtLine1Point) resulting in nil

Would it be possible for me to rewrite superflatten.lsp in such a way that extension defining points are always moved to Z=zero ? I would appreciate a nudge in the direction I would have to take in order to search a solution.

With friendly greetings, M. Moolhuysen.

[CAB]

Welcome to the Swamp moom.
I'm sure Joe will be along to answer you question.

[CAB]

I am surprised no one has an interest in this one but maybe I will have some spare time in the next few days to look at it.

[cadabyss]

JFYI, I am sure Joe will have an interest in this when he gets back after the Holidays.

[CAB]

Thanks Steve.

I took a quick look yesterday and it appears that the Dim Block which is difficult to access contains point objects which are the problem in this case.
The Z value needs to be changed to zero but I was not able to change them directly. Next attempt will be to change them while redefining the entire block but I have no spare time in the next two days.


Merry Christmas to All

[Joe Burke]

Hi,

I think I've seen this problem before, but an easy way to fix it wasn't obvious at the time.

I will test with your example file to see what can be done. Thanks for the example.

Also thanks to Alan for taking a look.

[Joe Burke]

moom,

Please let me know which version of SuperFlatten you are using.

Version 1.2c includes code which should flatten the point objects associated with a dimension object per your example file.

[CAB]

Which can be found here: http://www.theswamp.org/index.php?topic=18153.msg262911#msg262911

[Joe Burke]

A closer look at the issue reveals there was a rather strange problem going on. The 1.2c code apparently flattened the point objects in a dimension. But when the dimension was updated, the points returned to their former positions.

I hope the attached revised version 1.2d fixes the problem without causing any new ones.

[moom]

Today, I've tested version 1.2d on a real project drawing (with some substance). The original of this drawing had multiple objects with Z value other than zero and had multiple dimensions with defining points having a different Z-offset as the dimension line itself.

The SuperFlatten version 1.2d preforms well on this and seems to do all that is required, shifting the Z value of objects and of all aspects of the dimensions to zero. I like to thank Joe Burke for this update, it's very usefull for me.

A fruitfull newyear, M. Moolhuysen.

[Joe Burke]

You're welcome, though I think some similar problems with other types dimensions may still remain.

[moom]

If I'm not mistaken, I think that Linear, Arc Length, Diameter and Angular are the only dimension types for which it is possible that defining points are on a different Z-level than the Z-level of the dimension line itself. SuperFlatten version 1.2d works for Arc Length Dimension objects and Angular Dimension objects just as well as it does for Linear dimension objects.

I've also tested a Diameter Dimension object, of which I've changed the Z-level of the dimension line with the MOVE command (when it is moved, the defining points of the Diameter Dimension object stay on the original Z=zero plane). Here a funny difference occurs when I apply Superflatten:

• If the Diameter Dimension object is picked individually, its dimension line is moved to the Z=0 plane
• If the Diameter Dimension object is part of a selection, its dimension line is not moved

I did a quick test on a plain Leader object and a Radius Di menson object as well, and these work well with Superflatten. Note that when one shifts a Radius Di menson object to another Z-level with the MOVE command, it's two defining points shift also to the same Z-level (opposite to what happens when a Diameter Dimension object is shifted to another Z-level with the MOVE command).

With friendly greetings, M. Moolhuysen.

[Joe Burke]

Thank you for the feedback and time you spent testing.

I'm still studying the problem. I have another example file where all dimension points are not moved to Z zero. In this case the dimension type is Aligned.

I also agree there seems to be a problem related to a selection set which includes objects other than dimensions. Given my example file, if I only select the dimensions with points not at Z zero, all the dimension points are flattened as expected. But if I select all objects, one of the dimension points is not flattened correctly. Very strange, no solution yet.

[moom]

I'm sorry, I think now what I've written below here is incorrect

I also agree there seems to be a problem related to a selection set which includes objects other than dimensions. Given my example file, if I only select the dimensions with points not at Z zero, all the dimension points are flattened as expected. But if I select all objects, one of the dimension points is not flattened correctly. Very strange, no solution yet.

Maybe this behaviour is caused by the object order in the database. My theoretical line of thinking:

When the Diameter Dimension object is processed before the Circle object that it is attached to, it's dimension line will shift to the Z=zero plane, but its two defining points stay attached to the circle. After this has happened, the circle object is processed, but when it is shifted to the Z=zero plate, it "pulls" the dimension line of the associated Diameter Dimension object along (with the circle) and away from the Z=zero plane. You can simulate this by applying Superflatten separately on the Diameter Dimension object first and then on the Circle object.

When you pick the two objects separately, but the other way round (first Circle and then Diameter Dimension) both are flattened correctly. If this is true, a possible solution would be to filter the selection set in such a way that the Diameter Dimension objects gets processed last.

With friendly greetings, M. Moolhuysen.

[Joe Burke]

Thank you for your reply.

Further testing indicates your thought regarding associative dimensions is correct. Using my test file and SF version 1.2d recently posted, the one dimension which did not flatten was associative. It flattened correcly after changing it to non-associative.

So I need to add some code which checks for associative, which I have, then change the dimension to non-associative if it needs to be flattened. I'm not sure how I'll do that yet. Look for a revised version in the next few days.

BTW, the code also needs to be updated to deal with things like multiline attributes. I'm not sure whether that update will be included.

Thanks again