Embed Doc
Copy Link
Readcast
Collections

CommentGo Back

Download

VBA: Integrating with Microsoft Excel - Part 1

Bydave-espinosa aguilarThis article is the first in a series on integrating the programming power of AutoCAD® VBA with the functionality found in other Windowsapplications—specifically, Microsoft Excel. Through Visual Basic programming within AutoCAD, you can launch Excel and bring the full power of aspreadsheet application into an AutoCAD drawing session. The information in this series will demonstrate how to generate, organize, query, andextract linework visibly or behind the scenes during an AutoCAD session without spending a dime on additional compilers or documentation. If youhave AutoCAD and Microsoft Excel already loaded on your workstation, this technology is ready and waiting for you to take advantage of it.To enter the world of Visual Basic programming and add Excel functionality to AutoCAD software, you have to be willing to spend the time it takesto master this object-oriented programming tool. Even if you've programmed in AutoLISP® before, Visual Basic is not as forgiving or asaccommodating, and the rules that must be obeyed for everything to work right when you run your own VB applications are very strict. This isn't tosay that an AutoLISP programmer can't conquer the world of Visual Basic; it just takes more dedication and effort.So... as with any serious investment of your time, it pays to step back and examine what getting up to speed on Visual Basic (and the integration of AutoCAD VBA and Microsoft Excel) brings to your table in the first place. The more you learn about the software you already own, the morepowerful it gets and the more impact it stands to have on your productivity. If the nature of your drawings and designs lends itself to spreadsheetfunctionality, then consider setting aside notions of cranking out code, and go Zen with me for a bit as we consider some potentially profoundquestions... beginning with "Why should any AutoCAD user care that integration of AutoCAD and Microsoft Excel is even possible?"

Reason #1: Automated

Fully Customizable Part Counts

Have you ever counted entities in a drawing manually? By that I mean to ask have you ever (with your finger or pencil) tallied every parking lot spaceor every chair or every toilet in a bathroom or window on an exterior building wall or every HVAC fixture throughout a series of roof plans? Haveyou every counted sprinklers or landscaping features by plant type, bolts or screws for an assembly, or datapoints for a given site plan? Imaginepressing a menu button and being done with the process!

Reason #2: Queries

Maybe you use blocks with attributes. Have you ever wished you could count blocks (or maybe even select them) based on the values in thoseattributes? Maybe you use Extended Entity Data, which attaches gobs of unique information to individual entities. Wouldn't it be slick if there were aneasy way to take the sum or average of that information within seconds?There are some ingenious tricks and techniques out there like using the old SSX.LSP routine, the internal FILTER command and various otherfiltering functions in AutoCAD, layer isolations, the ATTEXT Block Attribute extraction to CDF/SDF command, and even basic select-objectstechniques to report entity counts in a drawing. But none of them come close to the reporting, querying, and attachment control that a linkedspreadsheet application can offer.Want to specify the name of a block with an attribute value that falls within a certain numeric range and have those entities meeting that criteriareported with full text formatting in a real spreadsheet template? You can with VBA. Imagine reporting attribute information or extended entity datafrom entities based on their location in the drawing or even based on the way in which they are being used or were originally generated (for example,count all blocks named "x" that were inserted by CAD operator "y" during month "z" of last year). If you're a SQL guru, you could actually queryblocks with attribute data using a SQL query statement—entirely through VBA.

Reason #3:

Portability and Data Reporting

Are there people in your office who use Excel with the same impressive proficiency that you use AutoCAD software? Have you ever wanted to shareyour AutoCAD information with them in a format with which they can easily work? Through coding, you can convert any kind of AutoCADinformation into a format that speaks another Windows application's language. You can translate your vector base into a grid base or a record base.You can view, report, and analyze drawings with all the usual analytical bells and whistles in a spreadsheet (flow charts, pie diagrams, trend charts,and so on) so that non-AutoCAD users using their native reporting methods and their native graphical tools can easily understand that AutoCAD data.

Reason #4:

Externalized Data

The golden rule of CAD drawing performance: small = fast. An AutoCAD session is never faster to work with than when you start it up. From thenon, everything just goes downhill in terms of speed and performance. It makes sense to bust out any information in a drawing that is not immediatelyrelevant to the work being done. For example, attributes eat up memory and they're cumbersome to work with. Why not store them (associated withthe relevant entities) in spreadsheet cells rather than as nested entities in a drawing?Data externalization provides two terrific benefits: external editing and manipulation of data and drawing-size reduction, which increases drawingperformance. It is possible to open a spreadsheet and change the value of a cell without ever opening AutoCAD. Can you imagine how easy it wouldbe to swap values of certain cells using Excel sorting/replacing or reformatting functions and have those changes immediately reflected in AutoCADblock attributes? How much smaller would your drawings be (and how much faster would they load, save, regenerate, and edit) if attribute entitieswere completely removed from them? And while we're discussing attributes...

Reason #5:

Hard-Coded Textual Options

Now this one might really play with your mind. Imagine that you could control (hardwire) those values you allowed to be entered for any particularuse of text or blocks with block attributes. For example, imagine that when you open a drawing, it reads information read from a spreadsheet andautomatically sends that data to a title block. Imagine that you could provide your users a combo box of preset textual or numeric values for anyblock's attribute values (based on the block name no less) when those blocks are inserted. And imagine that the hardwired set of values was controlledin a password-protected master spreadsheet file so that only certain users could change the allowed values for those block attributes? There areactually ways (using AutoCAD VBA and Excel) to do this kind of thing. The stuff of dreams.

Reason #6:

Tabulation

In an AutoCAD drawing, put a bunch of text entities with numeric values (for example, currency) in a vertical column (see Figure 1). Now add themup and report that value at the bottom of the column. Oops! Something changed. Edit one of the text entity values and retotal everything. Find theiraverage value or their minimal value or their maximum value and report that, too, at the bottom of the column. Oops! Sales tax just went up! Increaseall of the text entity values by a new percentage value and change the new total at the bottom of the column. Are we having fun yet?For years, people have been using TEXT entities to report tabulated data on drawings without the benefit of tabulation tools to do it, and a TEXTentity doesn't know the difference between a dollar and a toilet. Spreadsheets have been cranking out this kind of information for over a decade. Think hard about this one, folks. Maybe, just maybe, the process of creating schedules is possible without getting a headache.

Figure 1: Creating a schedule even this simple is time-consuming to construct and tallywithout a spreadsheet.

Reason #7: True Text-Formatting Control

At the recent AUGI® Annual General Meeting, the top 10 wish-list items were announced for the year and right up there near the top (for theumpteenth year in a row) was "tabbing for MTEXT"). If you've ever tried to align columns of TEXT or reorganize the line-by-line textual content of an entity after its assigned width space changed (a very painful process), or if you've ever tried to perform any number of basic text-formatting

manipulations within AutoCAD software (which are a cinch to do in Excel), you know how hard it is. Now you don't have to wait for such tools. Byimporting spreadsheet data (or even my linking and/or embedding it), you can bring full text control to your AutoCAD drawings (see Figure 2).Changing the assigned width of columns of textual or numerical data can be as simple as a drop-and-drag operation.

Figure 2: When you bring Excel grids into your drawings, you have complete control overtext formatting, column width, cell border thickness, and even background patterning.

Reason #8: Formulas?

What else can a spreadsheet do with data in a cell? Well for one thing, it can contain a formula to generate cell content based on other cells. Thatmeans that you can actually apply formulas for TEXT entities in your drawings! Aside from obvious uses of this capability (such as generating totalsafter a part count), you could even use Excel to figure out (through conditional states) what text, notes, or details need to be imported into a drawingbased on parts found in a drawing. Yes, folks... this starts getting wild.

Reason #9: Automated

Linework Generation

And while we're on the subject of things being imported based on queries and tallies and other amazing spreadsheet operations, we can also generatelinework itself from spreadsheets. You can convert databases to an Excel format, and easily view and edit them. And once you have that data in aspreadsheet format, it is possible to start generating linework from it! Imagine that you have a basic COGO point set of X, Y, and Z values brokendown into three columns. Contour lines or TINs could be generated from this information.

Reason #10: Costing

Out a Drawing

Excel spreadsheets make great reference tables. Imagine that you have a list of prices for items you insert into your drawings, and imagine that youwant a part count and a financial assessment of a drawing. To do this, you can begin with surveys of the entity database, pulling the necessarycomputational information into preset columns in a spreadsheet, and then price out the cost of the entire project based on an entirely differentspreadsheet of price-per-item values. Inventories on steroids, and generated no less by a CAD user!I could give you in a heartbeat another 10 reasons to think seriously about this stuff, from enhanced job opportunities and more competitive salaries tothe complete historical tracking of any drawing. In the coming articles, we'll examine sample code and develop microapplications that accomplish thetypes of operations described above. And it's not miracle working. It is, however, exciting and profitable stuff... for anyone willing to learn the game.