Accessing DescriptionKeySets via VBA

Does anyone know of a way to access the DescriptionKeySets of a Civil 3D
drawing using VBA? I'd like to be able to drill down to the individual Keys
and change some of the data in the fields, such as Fixed Scale Factor or
Point Style. I must be missing something. Thanks in advance.

 

Hi Wade,

It's very straight forward with either ADO or DAO.

The one thing is that you will have to do some experimenting with manual
changes so you know the interpretations of the keys holding the data about
which items are toggled on and off in the scaling settings and how the
parameters numbers are stored etc.
Block names, Layer names and Full Description should be easy to recognise.

But since Autodesk already provides you with an interface to do this, or you
can open the file in Excel and edit it, save it to a comma separated file
and import it back to Access, I'm curious at to what advantage you see in
programming it.

--


Laurie Comerford
CADApps
www.cadapps.com.au

 

Thanks for the reply,

I'm looking for a way to edit the Fixed scale factor. If I have 30 keys and
each one starts with Tree (Tree1 for a 1" tree, Tree2 for a 2" tree, ...
Tree30 for a 30" tree) and my Fixed scale factor is 1 for Tree1, 1.12 for
Tree2, 1.24 for Tree3, etc. I then find that all my trees are too small (or
too big) so I want to change the scale factor to 10% larger (or smaller)
than what it currently is. (Scale factor for Tree1 would change to 1.1,
Tree2 would change to 1.23, Tree3 would change to 1.36). I don't see a way
to do this without going into every key, calculating the new number by hand,
then entering the new number by had. If there is a way to import this
information from excel (csv) or something similar, I would be interested in
hearing about it.

Or if I wanted to change all keys that have a certain Point Style to a
different one.

Wait..I might have found a way to increase the scale of all the trees, under
the Point Styles, Marker tab, change the "inches" from the default of 0.1 to
whatever I need -- That worked.

....I guess I could do the same for changing the Points styles of the keys
too. (too much new stuff, my thinking is getting cloudy).

Another question though, I'm using the same symbols in Civil 3D as in LDD
2004. If I set the drawing up to the same scale in both versions (50 scale)
and I insert the points from the same PNEZD file, the symbols are smaller in
the Civil 3D drawing than they are in the LDD 2004 drawing. I have to scale
all the symbols up by 1.811 to be the same as LDD. Why is that?

 

Hi Wade,

If you do your trees that way all you are doing is making work.

Set the system up so that the tree is scaled by parameter 1

The code your trees as

TR 1
TR 2.345
TR etc,

The block is then scaled by the number, regardless of what the number is.

--

Regards,


Laurie Comerford
www.cadapps.com.au

 

Laurie,

I thank you again for your response. This is the reason why we don't use
scaling parameters:

I've been aware of the scale parameter for quite some time - LDD had/has it
and maybe even Softdesk. I don't think it works they way we want it to.
For example, a TR 60 (a tree that measures 60" in dia 4' above the ground)
is 60 times bigger than a TR 1 (a 1" dia tree). But in the drawing we don't
want the 60" tree symbol to be 60 times bigger than the 1" tree symbol -
that would clutter the drawing up too much (and if we came up with an
acceptable max symbol size, the 1" tree would be too small). So we came up
with a maximum and minimum symbol size and just prorated all the other sizes
in between. So a 5" tree may be 1.3654 times bigger than a 1" tree, or a
20" tree may be 3.3123 times bigger than a 1" tree. So we either have to
have 60 different tree blocks or have 1 tree block and 60 different Fixed
Scales. So the amount of work in the office is the same. We can't have the
surveyors (and draftspeople) remember that a TR 2.3421 is really a 12" dia
tree, and we can't have the surveyors type "TR 2.3421 12Oak" because that is
too many keystrokes in the field (especially when the temperture is in the
single digits). A code of "T12Oak" (with a desc key of T12*) is much more
efficient - it limits the keystrokes, inserts the appropriately sized
symbol, and still tells the draftsperson what the symbol represents.

We've also thought of a numbering system for the codes (i.e. 112 for a 12"
Oak, 212 for a 12" Pine) but that has its drawbacks too. 1) Everyone
(surveyors, draftspeople) need to memorize the codes - Is a 100 series for
Oaks, Beeches, Pines, Birches, etc.? 2) Its too easy to type the wrong code
and not notice - transposing numbers or accidentlly hitting a 1 instead of a
2.

Laurie, you mentioned that accessing the info thru ADO or DAO is straight
forward, but I'm still missing something. I don't know the names of the
recordsets Autodesk uses. In a Microsoft Access database for example I know
the names of the recordsets so I can establish a connection to the
recordset(s) and traverse thru the fields.

Can you give me an example of how to access the recordsets and/or point me
the direction of where I can find more info (I'll have a related post about
how to access the information of point objects (Number, Elev, Desc, XYZ
coord) soon)

Thanks again.

 

Hi Wade,

Firstly, let me say you'll never do a survey for me if you arbitrarly change
the scale of objects which I expect to be at scale.

A record set is simply a variable you define in your code. You don't need
to know someone else's name for a record set.

As I said in the first post, you will need to open a points database and
check the fields listed in the Points Table.
Here's an extract of some code I use in one of my programs using DAO. I'm
only interested in East, North, Elevation and Description. However by using
the * in SELECT * I have extracted all data in the table "points"

Dim Proj As AeccProject
Dim db As DAO.Database
Dim rs As DAO.Recordset
Dim lc As DAO.Recordset
Dim dNorth, dEast, dElev As Double
' On Error GoTo errhandler
Dim sDesc As Variant
Dim sPointList As String
Dim iCnt As Integer
Set Proj = AeccApplication.ActiveProject
Set db = OpenDatabase(Proj.FullName & "\cogo\points")
If Err.Number = 0 Then ' ie have been able to open database
Set rs = db.OpenRecordset("SELECT * FROM points ORDER BY NTH,PNO")
If Err.Number = 0 Then ' ie have been able to get data
rs.MoveLast ' Don't know why needed, but works
rs.MoveFirst ' Don't know why needed, but works
If Not rs.EOF Then ' Check if any data
Do While Not rs.EOF ' The code ends up with an error handled by
resume next
On Error Resume Next
dNorth = rs!nth ' Store point data for current point
dEast = rs!est
dElev = rs!elv
sDesc = rs!dsc
rs.MoveNext


--


Laurie Comerford
CADApps
www.cadapps.com.au

 

Thanks again for your response, unfortunately I don't think you understood
my original question (maybe I didn't explain it right)

I wasn't looking for the points database, I was looking for the Point
Description Keys. The points db is just an mdb file separate from the
drawing (and easy enough to get to via DAO or ADO - also it is possible to
have different points in the drawing than in the project db, like before you
do a "checkIn"), the Point Description Keys is an object within an AutoCad
drawing. Accessing the objects is different.

So just for the record, I was able to figure it out, here is the code I
used - in case anyone is interested (This code just reads the Description
Key file, finds a specific set, and puts the info in an array so that it can
be displayed in a listbox - its just an exercise in how to get to the info -
which is (in my opinion) the hardest step.):

Dim AeccApp As AeccApplication
Dim DescKey As AeccPointDescriptionKey
Dim DescKeyset As AeccPointDescriptionKeySet
Dim DKeySets As AeccPointDescriptionKeySets
Dim ADoc As AeccDocument
Dim MyNewArray() As Variant
Dim i As Long

Set AeccApp =
ThisDrawing.Application.GetInterfaceObject("AeccXUiLand.AeccApplication")
Set ADoc = AeccApp.ActiveDocument
Me.ComboBox1.ColumnCount = 2
Me.ComboBox1.ColumnWidths = "36;36"
i = 0
For Each DescKeyset In ADoc.PointDescriptionKeySets
If DescKeyset.Name = "Plants" Then

For Each DescKey In DescKeyset
i = i + 1
ReDim Preserve MyNewArray(2, i) As Variant
MyNewArray(0, i) = DescKey.Name
MyNewArray(1, i) = DescKey.FixedScaleFactor
Next DescKey
End If
Next DescKeyset
Me.ComboBox1.Column() = MyNewArray

Also note, the objects are not arbitrarily changed. We need to set up
standards in Civil 3D that match the standards set up in LDD. During the
setup process (done once before Civil is unleashed to the masses) the symbol
sizes need to be tweaked to match the sizes in LDD drawings. (I tried to
use the same scaling factors that we used in LDD but they ended up being
about 1.8 times too small (I don't know why such a weird number)). We've
had to do this when we went from Eaglepoint to Softdesk (I don't remember if
we needed to do it when we went from Softdesk to LDD). Once the standards
are established, then they are not changed (or at least not unless the
changes have gone thru some approval process). So if our standards are that
no symbol can be larger than a 50 cent piece and no smaller than 1/4 the
size of a dime we cannot have a 60 inch tree symbol be 60 times larger than
a 1 inch tree symbol - we have to prorate the sizes accordingly to fit the
standard criteria. I don't know of any survey companies that would allow a
symbol to take up 1/2 of a 24x36 sheet of paper just so that a smaller
version of that symbol is readable. So it is much easier to tweak all the
ScaleFactor settings programmically than it is to open up each Description
Key, click the ScaleFactor, enter the new number (and make sure I typed it
in right), then move to the next.

 

Hi Wade,

Sorry for the reference to the Points file, instead of the Description Keys
file. The code obviously referred to the Points file as it was a sample of
using DAO. I've never considered writing code to change a static file like
the Description Keys file.


"Also note, the objects are not arbitrarily changed."
"Once the standards

Within your company you have made up some scaling factors based on
appearance in the drawing. If these factors are not arbitrary, then you are
clearly using a different dictionary from me.

If I survey a tree and when plotting it to size it occupies the whole
drawing file - that's a fact. I cannot accept that it should be reduced in
size so that it doesn't occupy drawing space.

If I survey a Survey Mark, I want to show it as a symbol at the same size
regardless of plotting scale.

To what sort of objects are you applying your scaling factors wherein the
above principals don't apply.

--


Laurie Comerford
CADApps
www.cadapps.com.au

 

Laurie, normally when we survey a tree
it's trunk, and it's shadow, we plot it as it is, real size.
But we've had some clients that also need
the same drawing, but showing only the location
of the trees and a relative size, not their real size.
These drawings may be used for marketing purposes.

 

Hi Jorge,

For marketing and this type of drawing, why would you bother surveying? I'd
use Symbol Manager, perhaps with an aerial photo as an imagination guide.

--

Regards,


Laurie Comerford
www.cadapps.com.au

 

Marketing comes after the surveying and design has been done
so why complicate matters with photos and extra symbols
when the same dwg, with some tweaking and color fills, can do the job ??

Maybe your mind is set on something else.