AutoCAD Architecture Customization
Welcome to Autodesk’s AutoCAD Architecture Customization Forums. Share your knowledge, ask questions, and explore popular AutoCAD Architecture Customization topics.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Layer Key Styles in a Drawing

7 REPLIES 7
Reply
Message 1 of 8
David_W_Koch
1139 Views, 7 Replies

Layer Key Styles in a Drawing

Background:  I had an AutoLISP application that was able to display a list of the Layer Key Styles in a drawing in a dialog box and allow the user to select one and then generate all of the layers defined by the Layer Keys in that Layer Key Style.  I was able to get the dictionary data for the layer key styles using

 

(dictsearch (namedobjdict) "AEC_LAYERKEY_STYLES")

 

and then step through the dictionary data, extracting the Layer Key Style names and entity names.  This worked just fine in ADT 2004 when I developed it, and for several subsequent releases.  At some point, a chanbe was made and the data inside AEC dictionaries was no longer accessible by this method.  (And not just for Layer Key Styles:  I also had a way to get to the Annotation Plot Size using a similar technique, and have not been able to find a way to extract this in AutoLISP.  This is, no doubt, accessible via .NET, but I am not going to be able that is not going to happen for me anytime soon.)

 

Problem:  I have been searching for an alternate method of getting to this information, within the AutoLISP environment, both for this application and several others that relied on dictionary searches to retrieve that information.  Today, I stumbled onto an old post that pointed me in the right direction.

 

(vla-GetInterfaceObject (vlax-get-acad-object) "AecX.AecArchBaseApplication.7.5")

 

The above will get me the AecArchBaseApplication object in ACA 2014, and I can then use other Visual LISP commands to pull properties from within that.  Unfortunately, Layer Key Styles are in the AecBaseApplication object, and while

 

(vla-GetInterfaceObject (vlax-get-acad-object) "AecX.AecBaseApplication.7.5")

 

will get me the AecBaseApplication object [#<VLA-OBJECT IAecBaseApplication 0000000030f9c4c0>], I am not able to retrieve any information from within that object.  For example:

 

(vlax-dump-object (vla-GetInterfaceObject (vlax-get-acad-object) "AecX.AecBaseApplication.7.5"))

 

yields:

 

; IAecBaseApplication: AEC base application object, extending the AcadApplication object to provide support for general AEC objects
; Property values:
;   ActiveDocument = Exception occurred
;   Application (RO) = Exception occurred
;   Caption (RO) = Exception occurred
;   Documents (RO) = Exception occurred
;   FullName (RO) = Exception occurred
;   Height = Exception occurred
;   HWND (RO) = Exception occurred
;   HWND32 (RO) = Exception occurred
;   LocaleId (RO) = Exception occurred
;   MenuBar (RO) = Exception occurred
;   MenuGroups (RO) = Exception occurred
;   Name (RO) = Exception occurred
;   Path (RO) = Exception occurred
;   Preferences (RO) = Exception occurred
;   StatusId (RO) = ...Indexed contents not shown...
;   VBE (RO) = Exception occurred
;   Version (RO) = Exception occurred
;   Visible = Exception occurred
;   Width = Exception occurred
;   WindowLeft = Exception occurred
;   WindowState = Exception occurred
;   WindowTop = Exception occurred
T

 

Attempts to retrieve just one property value also fail.  So is there a way around this, or do I have to live without these functions until such time as I can teach myself .NET?  I hold out hope, as vla-GetInterfaceObject is not listed as a Visual LISP command under the "V" commands. 


David Koch
AutoCAD Architecture and Revit User
Blog | LinkedIn
EESignature

7 REPLIES 7
Message 2 of 8
David_W_Koch
in reply to: David_W_Koch

I need to look into this more closely, but in 2013 and 2010, it appears that the LayerKeyStyles property is available through the AecArchBaseApplication, even though it appears under the AecBaseApplication in the Object Model.  Works for me, so long as it gives me access to the data I need.

 

The Annotation Plot Size also appears to be "hiding" as the TextHeight property, available through the AecArchBaseApplication's ActiveDocument Preferences object.  I had thought that was in the AecBaseApplication, too, but the object model indicates the value is in both, and the value matches the Annotation Plot Size value and changes when the Annotation Plot Size value changes.

 

Progress!


David Koch
AutoCAD Architecture and Revit User
Blog | LinkedIn
EESignature

Message 3 of 8
Gary_J_Orr
in reply to: David_W_Koch

This if for 2013, so of course the ref would to version would need to be modified for 14. It's a simple dump of the keys and includes an "IF" clause that can be modified to look for a specific keystyle or omitted to parse through all of them.

 

(defun C:GetLayerKeys ( / )
  (textpage)
  (setq AECBASEObject (vla-getinterfaceobject (vlax-get-acad-object) "AecX.AecArchBaseApplication.7.0"))
  (setq currAECDoc (vla-get-activedocument AECBASEObject))
  (setq KeyStylesCol (vlax-get-property curraecdoc "LayerKeyStyles"))
  (vlax-for EachLayKeySty KeyStylesCol
    (setq LayerKeyStyleName (vla-get-name EachLayKeySty))
    (if (wcmatch (strcase LayerKeyStyleName) (strcase "AIA (256 Color)"))
      (progn
 (princ "\n")
 (princ LayerKeyStyleName)
 (princ "\n")
 (vlax-dump-object EachLayKeySty)
 (setq KeyCol (vlax-get-property EachLayKeySty "Keys"))
 (vlax-for EachLayKey KeyCol
   (vlax-dump-object EachLayKey)
   ); vlax-for keys
 )
      );if
   
    );vlax-for keystyles
  (princ)
  )

Gary J. Orr
(Your Friendly Neighborhood) CADD/BIM/VDC Applications Manager
http://www.linkedin.com/in/garyorr

aka (current and past user names):
Gary_J_Orr (GOMO Stuff 2008-Present); OrrG (Forum Studio 2005-2008); Gary J. Orr (LHB Inc 2002-2005); Orr, Gary J. (Gossen Livingston 1997-2002)
Message 4 of 8
David_W_Koch
in reply to: Gary_J_Orr

Thanks!  I had done some additional digging, and had found that the AecArchBaseApplication object also gave access to the Layer Key Styles.  I also managed to find the place where the Annotation Plot Size is hidden.  The ActiveDocument property of the AecArchBaseApplication gives the object for the currently active drawing file.  That object has a Preferences property that gives the AecArchBasePreferences object, which in turn has a property called TextHeight, which is the Annotation Plot Size.

 

I am still working on finessing the current effective drawing/annotation scale.  The AecArchBasePreferences object has a DatabaseScale property that gives the current model tab scale, but if Model Space is active in a viewport on a Layout, I also want to know what that viewport's drawing scale and, if different (they often are the same, but can be different), annotation scale are, so that if I have a routine to draw an annotation item, it does so using the current annotation scale.  The StandardScale and StandardScale2 properties appear to be the key here, but I have not had time to work out how the Enum values given in the ActiveX help translate to the values returned by these properties.  Unfortunately, this project is not on the critical path, so I can only work on it when I find time between other tasks.

 

I appreciate your response.


David Koch
AutoCAD Architecture and Revit User
Blog | LinkedIn
EESignature

Message 5 of 8
David_W_Koch
in reply to: David_W_Koch


@Anonymous wrote:

Thanks!  I had done some additional digging, and had found that the AecArchBaseApplication object also gave access to the Layer Key Styles.  I also managed to find the place where the Annotation Plot Size is hidden.  The ActiveDocument property of the AecArchBaseApplication gives the object for the currently active drawing file.  That object has a Preferences property that gives the AecArchBasePreferences object, which in turn has a property called TextHeight, which is the Annotation Plot Size.

 

I am still working on finessing the current effective drawing/annotation scale.  The AecArchBasePreferences object has a DatabaseScale property that gives the current model tab scale, but if Model Space is active in a viewport on a Layout, I also want to know what that viewport's drawing scale and, if different (they often are the same, but can be different), annotation scale are, so that if I have a routine to draw an annotation item, it does so using the current annotation scale.  The StandardScale and StandardScale2 properties appear to be the key here, but I have not had time to work out how the Enum values given in the ActiveX help translate to the values returned by these properties.  Unfortunately, this project is not on the critical path, so I can only work on it when I find time between other tasks.

 

I appreciate your response.


The StandardScale and StandardScale2 properties are obtained from a viewport object, which also has a CustomScale property.  The latter appears to be the drawing scale of the viewport, expressed as a decimal of the ratio of paper space linear unit/model space linear unit.  So for 1/8" = 1'-0", the CustomScale value would be 0.01041666 (1/96).  If the Custom Scale is a standard scale, then the StandardScale and StandardScale2 properties are set to an integer values that I assume correspond to the scale assigned, although the Developer Help claims they should be set to enums like acVp1_8in_1ft.  And even when the drawing and annotation scales are the same, the integer values for StandardScale and StandardScale2 vary.  I hope to be able to test values and make some sense of this soon.

(PS:  Just to be different, the DatabaseScale property of the AecArchBasePreferences object is given as the ratio of real-world units/drawing units, or the inverse of the CustomScale property noted above.  So for 1/8" = 1'-0", the DatabaseScale property is 96.0.)


David Koch
AutoCAD Architecture and Revit User
Blog | LinkedIn
EESignature

Message 6 of 8
David_W_Koch
in reply to: David_W_Koch

In my limited testing, it seems as though the StandardScale enum ties back into a "fixed" list of enums that correspond to typical drawing scales:

 

0 = acVpScaleToFit = scale to fit

1 = acVpCustomScale = custom (non-standard) scale

2 = acVp1_1 = 1:1

3 = acVp1_2 = 1:2

4 = acVp1_4 = 1:4

5 = ???

6 = acVp1_8 = 1:8

7 = acVp1_10 = 1:10

8 = acVp1_16 = 1:16

9 = acVp1_20 = 1:20

10 = acVp1_30 = 1:30

11 = acVp1_40 = 1:40

12 = acVp1_50 = 1:50

13 = acVp1_100 = 1:100

14 = acVp2_1 = 2:1

15 = acVp4_1 = 4:1

16 = acVp8_1 = 8:1

17 = acVp10_1 = 10:1

18 = acVp100_1 = 100:1

19 = acVp1_128in_1ft = 1/128" = 1'-0"

20 = acVp1_64in_1ft = 1/64" = 1'-0"

21 = acVp1_32in_1ft = 1/32" = 1'-0"

22 = acVp1_16in_1ft = 1/16" = 1'-0"

23 = acVp3_32in_1ft = 3/32" = 1'-0"

24 = acVp1_8in_1ft = 1/8" = 1'-0"

25 = acVp3_16in_1ft = 3/16" = 1'-0"

26 = acVp1_4in_1ft = 1/4" = 1'-0"

27 = acVp3_8in_1ft = 3/8" = 1'-0"

28 = acVp1_2in_1ft = 1/2" = 1'-0"

29 = acVp3_4in_1ft = 3/4" = 1'-0"

30 = acVp1in_1ft = 1" = 1'-0"

31 = acVp1and1_2in_1ft = 1 1/2" = 1'-0"

32 = acVp3in_1ft = 3" = 1'-0"

33 = acVp6in_1ft = 6" = 1'-0"

34 = acVp1ft_1ft = 1'-0" = 1'-0"

 

I say "fixed", but I could be wrong about that.  I did not see any way to add or delete scales from the above list.  This was in an imperial drawing, so I do not know if there are different scales associated with these enums in a metric drawing.  And since I worked backwards from the "acVp" versions as listed in the Help to determine the associated integer value (which is what the StandardScale property holds), I have no idea if 5 means something.  I also was surprised to see that there are no imperial engineering scales (1" = 30'-0", for example - which is NOT 1:30, but 1:360).

 

If that were not vague enough, the StandardScale2 values, which correspond to annotation scale assigned to a viewport.  This list can be customized, and the integer values associated with a particular scale will change when the list is changed; they appear to be assigned in the order the scales appear on the list.  For the out-of-the-box settings, I found the following:

1 = Scale to fit (you really cannot pick this as an annotation scale, but if the viewport scale and the annotation scale are synchronized, and the viewport scale is not a standard scale, then StandardScale2 will be set to 1)

2 = 1/32" = 1'-0"

3 = 1/16" = 1'-0"

4 = 3/32" = 1'-0"

5 = 1/8" = 1'-0"

6 = 3/16" = 1'-0"

7 = 1/4" = 1'-0"

8 = 3/8" = 1'-0"

9 = 1/2" = 1'-0"

10 = 3/4" = 1'-0"

11 = 1" = 1'-0"

12 = 1 1/2" = 1'-0"

13 = 3" = 1'-0"

14 = 6" = 1'-0"

15 = 1'-0" = 1'-0"

 

If you add scales, then the numbers shift from the added scale on down.  I was starting to worry that I would have to find where in the registry the annotation scales were kept, and write a function to read them in order and then figure out how to assign the right scale factor, when I remembered the CANNOSCALEVALUE system variable, which holds the inverse of the scale factor I wanted for the current annotation scale.  So in conditions where TILEMODE = 0 and Model Space is active, I can get the viewport magnification scale from the inverse of the viewports CustomScale property and the annotation scale from the inverse of the value in CANNOSCALEVALUE, and avoid dealing with scale enums altogether.


David Koch
AutoCAD Architecture and Revit User
Blog | LinkedIn
EESignature

Message 7 of 8
David_W_Koch
in reply to: David_W_Koch


@Anonymous wrote:

Thanks!  I had done some additional digging, and had found that the AecArchBaseApplication object also gave access to the Layer Key Styles....


My current stumbling block on this task is that when I try to generate the list for our office-standard Layer Key Style, which has Layer Keys from ACA and AMEP plus some others that we added, the routine I wrote to create a list of strings of all of the Layer Key names fails.  The error message at the Command prompt states "Automation Error. Description was not provided."  If I run in on any of the ACA out-of-the-box Layer Key Styles, it works fine (working mostly in 2010 at this point).  The AecLayerKeyList LISP function (defined in AecLMgrLISP.arx) works on our office-standard list, so it cannot be just that the list of strings exceeds the carrying capacity of a LISP variable.  Unfortunately, that only returns the Layer Keys for the currently active Layer Key Style; for my routine to work fully, it needs to be able to get to any of the Layer Key Styles defined in the drawing, and I would prefer to not have to change the current Layer Key Style to access the list of Layer Keys for the non-current Layer Key Styles.

 

I have to find time to dig into this further.  Unfortunately, the lack of any sort of description for the error makes it hard to guess what the problem might be.


David Koch
AutoCAD Architecture and Revit User
Blog | LinkedIn
EESignature

Message 8 of 8
David_W_Koch
in reply to: David_W_Koch


@Anonymous wrote:
My current stumbling block on this task is that when I try to generate the list for our office-standard Layer Key Style, which has Layer Keys from ACA and AMEP plus some others that we added, the routine I wrote to create a list of strings of all of the Layer Key names fails.  The error message at the Command prompt states "Automation Error. Description was not provided."  If I run in on any of the ACA out-of-the-box Layer Key Styles, it works fine (working mostly in 2010 at this point).  The AecLayerKeyList LISP function (defined in AecLMgrLISP.arx) works on our office-standard list, so it cannot be just that the list of strings exceeds the carrying capacity of a LISP variable.  Unfortunately, that only returns the Layer Keys for the currently active Layer Key Style; for my routine to work fully, it needs to be able to get to any of the Layer Key Styles defined in the drawing, and I would prefer to not have to change the current Layer Key Style to access the list of Layer Keys for the non-current Layer Key Styles.

I have to find time to dig into this further.  Unfortunately, the lack of any sort of description for the error makes it hard to guess what the problem might be.


I finally found a little time to dig into this.  It turns out that it had nothing to do with the number of layer keys in our Layer Key Style.  The problem was there was a "bad" Layer Key in it.  Index 237 was causing the crash.  I worked this out by modifying a copy of the routine and having the copy write each processed Layer Key name to a text file.  237 Layer Key names were successfully written (Indices 0 to 236).  An additional modification had it start at Index 238 and run to the end, and that worked just fine, too.  I compared the Layer Key names written to file under the two scenarios to the Layer Key names that appear in the Style Manager for that Layer Key Style, and it turned out they were identical, and that there were a total of 311 Layer Keys, while the Count for the Layer Key Style was 312.  I was able to use the Remove method for the LayerKeys object to remove Index 237 from the Layer Key Style, after which my original subroutine ran just fine.  I will have to remove the bad key at work, also.


David Koch
AutoCAD Architecture and Revit User
Blog | LinkedIn
EESignature

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Design & Make Report

”Boost