Dimen is Horiz or vert?

Hi all,
I was surprised not to find anything on this in google.
Maybe search terms "Dimension Horizontal Vertical" and combinations thereof
were not sufficient.
If this is a repeat please forgive and point to references.

I'm a bit surprised to see that with an IAcadDimRotated...
if it's a vertical dimension..
Rotation = 0
TextRotation = 0
if it's a Horizontal dimension...
you guessed it...
Rotation = 0
TextRotation = 0

I can't find any other properties that appear to distinguish the orientation
Maybe I'm missing something obvious.

For a while I was getting around this by reading the block def, getting the
start and endpoints and reading angle between them
Obviously this doesn't work because they can be offset from each other and
still the dim is horz or vert.

So now the only thing I can think of is get the three lines from the def.
If two are horz and one vert, it's a vert dim
If two are vert and one horz, it's a horz dim.

I could rely on the order of lines in the definition since they seem
consistent, and just read the dimension line (ignoring the extension lines)
but since there's no guarantee that will be the case I thought it safer to
check all three since there will always be two one way and one the other.

Is there something obvious I'm missing that's much easier?
This seems an absurd amount of work to find what i would have expected to be
a simple property get....

Tia
Mark

 

If the dimensions don't reside in a block, you could try something like:

Public Function IsDimVertical(objDim As AcadDimRotated) As Boolean
On Error Resume Next
Dim ss As AcadSelectionSet
ThisDrawing.SelectionSets.Item("IsDimVertical").Delete
Set ss = ThisDrawing.SelectionSets.Add("IsDimVertical")

Dim fType(0 To 4) As Integer
Dim fData(0 To 4) As Variant
Dim RetVal As Boolean

fType(0) = 0: fData(0) = "DIMENSION"
fType(1) = -4: fData(1) = ">"
fType(2) = 50: fData(2) = 1.57
fType(3) = -4: fData(3) = "<"
fType(4) = 50: fData(4) = 1.58

ss.Select acSelectionSetAll, , , fType, fData

Dim ent As AcadDimension
For Each ent In ss
If ent.Handle = objDim.Handle Then
RetVal = True
End If
Next
ss.Delete
IsDimVertical = RetVal
End Function

... if it return True, it is vertical, other wise it is horizontal.

- Lanny

 

Thanks for the idea Lanny,
It's good example of thinking outside the box.
I appreciate your help.
Without (hopefully) sounding ungrateful, my questions regarding that
approach are:
Would that be more efficient than reading the block definition
directly?
Somehow I would suspect to that reading the angle of three lines
would be less overhead than iterating a selection set of all "vertical"
dimensions.
Especially since the number of dimensions would vary per drawing and
could theoretically be many thousand entities.
Where as reading the block definition would always entail reading
three entities (at most)
That could even be reduced to reading only one entity - the last of
the three - since that appears to be the dimension line - I'm only
suggesting reading all three in case that order of return were to change in
future releases or someone were to prove my theory incorrect that the
dimension line is the last of the three to be returned.

At the minimum I would suggest one alteration to your approach were one
to use it.
in the for loop, once the target dim is located I'd put an exit for
there so the remaining dims don't need to be processed.
For Each ent In ss

Mark

 

On my first attempt, i did have the handle (dxf group 5) in the filters, but that didn't appear to work. We do cabinet shop drawings, an our drawings rarely ever exceed 100 dimensions, let alone a couple dozen. As far as reading the block definition, that would be faster. I'm just curious -- how do you first get the associated block from a known dimension?

 

but that didn't appear to work.

hmmm, now that's a good idea. wonder why that didn't work.

dimensions, let alone a couple dozen.

right, considering the larger number is just in recognition that different
trades dwgs can vary in complexity and size so it's something to think about
in general in terms of how efficient a given algorithm is going to be in
different circumstances.

curious -- how do you first get the associated block from a known dimension?

it happens that my current use for this is in a lisp routine
(setq blkname(cdr(assoc 2(entget(handent(vlax-get-property odim
'handle))))))
(setq blockObj (vlax-invoke-method blockCol 'item blkname))

I posted to vba group cause the essential question was about the dimension
object's properties.
IIRC vba has no equivalent of Handent so yet another hack would be required
to port to vba.

Thanks again for giving consideration to the question.
Mark

 

All the code for pulling the dimension's block def is
based on the fact that the block's name will be the dim's handle +2 [except
for the very first dim which is only +1]

Sub DimensionPts()
Dim vPickPt As Variant
Dim oDim0 As AcadDimension
Dim oDimDefBlk As AcadBlock
ThisDrawing.Utility.GetEntity oDim0, vPickPt, "Pick dimension: "
If Not oDim0 Is Nothing Then
If TypeOf oDim0 Is AcadDimension Then
Set oDimDefBlk = GetDefinition(oDim0.Handle)
........
End Sub

Function GetDefinition(sHandle As String) As AcadBlock
' Returns a dimension's controlling block
Dim oBlk As AcadBlock
Dim sLeft As String
Dim sRight As String
Dim bTest As Boolean
On Error GoTo Err_Control
sLeft = Left(sHandle, Len(sHandle) - 2)
sRight = "&H" & Right(sHandle, 2)
sRight = sRight + 1
sHandle = sLeft & Hex(sRight)
bTest = True
Set oBlk = ThisDrawing.HandleToObject(sHandle)
Set GetDefinition = oBlk
Exit_Here:
Exit Function
Err_Control:
Select Case Err.Number
Case 13 'Type Mismatch
If bTest Then
sRight = sRight + 1
sHandle = sLeft & Hex(sRight)
Err.Clear
'single increment only! Reset test
bTest = Not bTest
Resume
Else
'second time in or other mismatch
Err.Raise Err.Number, Err.Source, Err.Description, _
Err.HelpFile, Err.HelpContext
End If
Case -2147467259
Err.Clear
MsgBox "Invalid dimension entity...", vbCritical
End
Case Else
Err.Raise Err.Number, Err.Source, Err.Description, _
Err.HelpFile, Err.HelpContext
End Select
End Function

-- Mike
___________________________
Mike Tuersley
CADalyst's CAD Clinic
Rand IMAGINiT Technologies
___________________________
the trick is to realize that there is no spoon...

 

A rough equivalent of handent in vba is HandleToObject which returns an object reference given a handle. If you really need the ename you could then call the ObjectId property of the object. The problem would be in retrieving the association list. As you're working in lisp, why not just read the group 50 code?

 

All the code for pulling the dimension's block def is

That is an assumption, not a fact, and is invalid for copied dimensions.

 

Hasn't failed yet

-- Mike
___________________________
Mike Tuersley
CADalyst's CAD Clinic
Rand IMAGINiT Technologies
___________________________
the trick is to realize that there is no spoon...

 

object reference given a handle.

right, I misspoke when i mentioned handent
I really meant that (cdr(assoc 2(entget(handent oDim)))) is not directly
available via vba.
That line should simply be oDim.Name - however, as we all know - even though
the block has a name - as evidenced by the fact that lisp (assoc 2 returns
it - yet vb refuses to return that information.

right, in this example, since i'm in lisp - i could simply use code 50
The other end of the stick is, since lisp can get it with code 50,
why can vb *not* get it with oDim.Rotation - or oDim.Angle
When you have an interface named IAcadDimRotated and an instance of that
which is vertical has .Rotation = 0 and an instance which is Horizontal has
..Rotation = 0 there's just something wrong!
But maybe that's just me!

However I am over time trying to rewrite my lisp routines to vb or at least
trying to create newer routines either using activex lisp functions or vb
routines. I'm trying to creep my way into the object oriented view of the
world.
To that end I was just trying to find a direct object method to retrieve the
required information.

 

Thanks Mike,
I knew you had the trick for this but didn't remember exactly how it went.
Thanks
Mark

 

I was sure that copied dimensions would reuse a block definition until modified. I must have been mistaken.

Unless I'm misunderstanding your code the GetDefinition function will have a problem with input handles greater than &HFF ending in "FF", "00" through "0E", and possibly "FE".