July 26, 2010

Frozen Ribbon

No, it is not a new way to beat the summer heat (my apologies to readers in the southern hemisphere, who may be more interested in a way to stay warm, but this has been a particularly brutal summer here in Philadelphia); it is a frequently reported occurrence in AutoCAD® Architecture 2010 and 2011. Often triggered by the use of the MTEXT command, the freeze occurs if you have more than one CUIX file loaded and two or more each have a contextual ribbon tab (such as the Text Editor tab triggered by the MTEXT or MTEDIT commands) that is triggered by the same command or object selection.

This most frequently happens when both the ACA.cuix and ACAD.cuix files are loaded simultaneously, often so that an ACA user can have access to elements in the ACAD.cuix file that are not part of the ACA.cuix file. Unfortunately, loading both as they are, out-of-the-box, will result in having multiple contextual ribbon tabs for the same triggering action.

The solution is to either not load both at the same time, or, if you must have access to items in both, to create a custom CUIX file that has the items you want from the ACAD.cuix file, but does not have the contextual ribbon tabs (or at least not any that overlap those in the ACA.cuix file). You will need to decide whether it is easier to make a copy of the ACAD.cuix file under another name, and remove the overlapping contextual ribbon tabs -OR- set up a new CUIX file and transfer only the items you want/need from the ACAD.cuix file.

July 24, 2010

Revit Training from Paul Aubin via lynda.com

If you are interested in an Internet-based Revit® "Essentials" course that is available any time your are, you may want to look into subscribing to lynda.com, where Paul Aubin has added such a course. According to the website, subscriptions begin at $25.00/month. Premium subscribers (starting at $37.50/month) also get access to exercise files. The class consists of 8:25 of video instruction; you can get more details here.

Your subscription also provides access to training on AutoCAD, 3DS Max, Maya and Sketchbook Pro, as well as many other software titles.

July 20, 2010

Insertion Point of an AEC Object in AutoLISP

If you have ever tried to use AutoLISP to automate a task involving an AEC Object, you may have found that the ENTGET function does not return as much information for an AEC Object as it does for an AutoCAD object. A question posted to the Autodesk AutoCAD Architecture Customization Discussion Group, asking how the insertion point of a Multi-View Block might be obtained in AutoLISP, prompted me to see if I could figure out how to do just that. I knew that the Visual LISP ActiveX (VLAX) functions allowed for direct access to an object's properties. Unfortunately, the amount of time I have available for fun* things like writing AutoLISP code shrank significantly right around the time that the VL/VLAX/VLR functions were introduced, so I have never become proficient with them. Since this task was fairly simple, I thought I would take a shot at it anyway.

Using the 2010 Help (the 2011 Help no longer appears to have the AutoCAD Architecture ActiveX Reference section), I was able to determine that Multi-View Blocks (as well as a number of other AEC Objects) have a Location property that holds the "insertion point" as a variant three-element array of doubles. That means that the value is not pre-declared as a specific data type ("variant") and that it contains an array of three, double-precision real numbers ("doubles"), which is what you would expect to describe a 3D point. From previous experince, however, I knew that I would not be able to just assign that property value to an AutoLISP variable and use it with AutoLISP functions. I scanned through the VLAX functions, and saw the VLAX-VARIANT-VALUE function, the description of which indicated that it would return the value of a variant. That sounded like it was just what I wanted, but I found that for a variant containing an array, the return value was a "safearray", and that was not the simple list of three real numbers I needed. Fortunately, I also found the VLAX-SAFEARRAY->LIST function, which converts a "safearray" to an AutoLISP-style list of three real numbers. This may be less "safe", but it is far more useful when using AutoLISP functions.

The following code is what I posted in reply in the Discussion Group. There is no error checking in the subroutine, so it will crash if the entity name passed belongs to an object of a type that does not have a Location property. I am assuming that the calling routine will only pass entity names of objects that have a Location property; if that is not possible, then the subroutine would need to verify that the passed entity name belongs to a appropriate object type before trying to obtain the Location property. If the subroutine tests for appropriate object type, then a special "alert" return value should be included to inform the calling routine that an inappropriate entity name was passed.
(defun AECINS (ename / ob ptarray ptins)
(setq ob (vlax-ename->vla-object ename))
(setq ptarray (vlax-get-property ob 'Location))
(setq ptins (vlax-safearray->list (vlax-variant-value ptarray)))

* - Yes, I suppose it is sad that I find writing AutoLISP code "fun".