Without A Net

Reset Layer Viewport Overrides from VPLAYER

I recently received a question from a customer in Germany asking if there was any way, from the AutoCAD command line, to remove layer overrides from viewports (per-viewport layer overrides is a feature we introduced in AutoCAD 2008 that allows you to apply layer property overrides for color, linetype, lineweight and plot style, and make objects on a layer display differently in different viewports without affecting the global layer properties). Typically, you remove viewport overrides using the Layer dialog or the right-click context menu on a viewport object, however this customer needed a way to automate the process a bit more and drive it from the command line. As it happens, there is an undocumented way to do this.

The VPLAYER command includes the hidden keyword option reMoveoverrides. You won't see this keyword in the list of options but if you enter M at the initial VPLAYER prompt, you'll get a sub-prompt of options to remove one or all types of layer property overrides. You can choose which layers these overrides should be removed from and in which viewports.

In this example, I'm removing all the viewport overrides from all the layers in the current viewport:

In this example, I'm removing only the color override from only Layer1 in all the viewports:

VPLAYEROVERRIDESMODE

Of course, if you don't need to remove viewport overrides and just want to temporarily disable them, you can always use the VPLAYEROVERRRIDESMODE system variable. This is a quick way to globally turn layer overrides on and off in the current drawing.

Setting VPLAYEROVERRIDESMODE to 0 causes all layers in all viewports to display using their global properties. This is how everything would look if no viewport overrides were applied. The overrides are still in place, they just aren't displaying.

Setting VPLAYEROVERRIDESMODE to 1 causes all layers in all viewports to display using any assigned layer property overrides.

Note: Property overrides can still be assigned even when VPLAYEROVERRIDESMODE is set to 0. Also, all visual indications that a layer has overrides will still display even when VPLAYEROVERRIDESMODE is set to 0. This includes background colors and the Viewport Overrides layer filter in the Layer dialog.

Taking a Break

Well, that's likely my last post for the year. Autodesk employees are taking a couple of company furlough days and then shutting down for our annual week of rest. With the exception of staff dedicated to manning our critical systems, it will be a bit quiet from the Autodesk camp for the next two weeks.

On behalf of Dan Scales and myself, thank you for your questions, comments, and faithful reading of Without A Net. We'll be back again next year.

P.S., I don't know about you, but I enjoy this time of year because I can sound like a complete procrastinator: "Never mind, I'll do that next year."

License File Parser

In my last post where I talked about Error: -125,147, a comment was added by Matt Stachoni  from CADapult saying that he finds the License File Parser a useful tool. So, I guess now is a good time to provide some information on what it does.

The License File Parseris a relatively new on-line tool that can be used to convert your Autodesk license file into a more readable user friendly format.

 

To use the tool you simply go to www.licenseparser.com, click the "Browse" button, locate your license file and then click the "Submit License File" button.

After clicking the submit button the license information is displayed on screen in a clear easy to understand format.

The following example shows an AutoCAD 2010 subscription package license file.

 

As you can see from this example the License File Parser is a great way to see what is actually inside you license file without needing to manually decipher the *.lic file itself.

Command Versioning in AutoCAD

In AutoCAD 2009, Autodesk introduced the concept of command versioning. This functionality was added was to help ensure reliable playback from Action Macros by providing a method for the Action Recorder to initialize a specific version of a command on playback. When I refer to the version of a command I’m usually referring to the difference between how a command responds when invoked manually, e.g., typing, menu pick, etc., versus how the same command responds when invoked from automation like AutoLISP or scripts. For example: typing the COLOR command launches the “Select Color” dialog, whereas running (command “.color”) automatically runs the command-line version of the COLOR command. In that example, the automation method is considered the oldest version – version 1 – because it preceded the addition of a Color dialog. When entered manually, it is considered the latest version of the COLOR command, or version 2. The ability for you to request a specific version of a command is available through a new AutoLISP function and, to a more limited degree, through a new menu control code.

(initcommandversion)

The (initcommandversion) function can be used to initialize a version to be used by the next command that is run. It is similar to the (initdia) function in that it only applies to the command that is run immediately after calling (initcommandversion). Running (initcommandversion #) initializes a specific version of the command that follows (1 or 2). Running (initcommandversion -1) initializes the default version of the command (typically, the most recent version).

For example, running the COLOR command normally displays the Select Color dialog but the following will force the command-line version of the COLOR command even though it is being run manually:

Another example is the EXPLODE command. When run manually, EXPLODE allows for multiple selections before exploding the selection set (version 2). When run from automation, EXPLODE runs immediately after a single pick (version 1). You can force EXPLODE to use one behavior or the other by initializing the command version right before running the command. To force EXPLODE to run after a single pick, you could do the following:

Menu Macros

Command versioning for menu macros was a slightly different approach. Single-token menu macros automatically run the latest version of a command, e.g., ^C^C^P_3dconfig, in a menu macro, launches the “Adaptive Degradation and Performance Tuning” dialog. On the other hand, multiple-token menu macros automatically run a command as though it was driven by automation. For example: ^C^C^P_3dconfig ^P runs the command-line version of the same command because of the ^P at the end (this makes it a multiple-token macro). Preceding a command with the new ^R control code will force the command to run the latest version instead. For example: ^C^C^P^R_3dconfig ^P will cause the 3DCONFIG command to launch the dialog instead of running at the command line.

What commands support command versioning?

To date, there is only a small subset of AutoCAD commands that have been updated to support versioning:

-ARCHIVE, -COLOR, -ETRANSMIT, -GROUP, -IMAGE, -INSERT, -LAYER, -STYLE, -TABLE, -VIEW, 3DCONFIG, 3DMOVE, 3DROTATE, ABOUT, ARCHIVE, ARRAY, ATTDEF, ATTEDIT, ATTEXT, BCLOSE, BEDIT, BHATCH, BLOCK, BOUNDARY, BOX, BPARAMETER, BPOLY, BSAVEAS, BVSTATE, BWBLOCKAS, CHAMFER, CLASSICIMAGE, CLASSICXREF, COLOR, CONVERT, CONVERTCTB, CONVERTPSTYLES, COPY, COPYTOLAYER, CUILOAD, CUIUNLOAD, DDEDIT, DIM, DIMEDIT, DIMSTYLE, DTEXT, DWGCONVERT, DXFIN, DXFOUT, ETRANSMIT, EXECUTETOOL, EXPLODE, EXTRUDE, FILLET, GROUP, HATCH, HATCHEDIT, HELIX, HIDE, IMAGE, IMAGEADJUST, INSERT, LAYDEL, LAYER, LAYISO, LAYMCH, LAYMRG, LAYOUT, LINETYPE, LOFT, LWEIGHT, MASSPROP, MENULOAD, MENUUNLOAD, MLEADER, MLEDIT, MOVE, MTEXT, MVIEW, OPENDWFMARKUP, OSNAP, PAN, PLOTSTAMP, PSETUPIN, PSOUT, PURGE, QUICKCALC, RENAME, RENDER, REVOLVE, SCALE, SHADE, SHADEMODE, SOLIDEDIT, STRETCH, STYLE, TABLE, TABLEDIT, TABLESTYLE, TOOLBAR, UNITS, VBALOAD, VBARUN, VIEWPORTS, VPLAYER, VPORTS, WBLOCK, WSSAVE, XBIND, XREF

These are the commands that needed to be updated in order to get reliable recording and playback with the Action Recorder. In many cases, it was only one or two aspects of a command that actually needed updating. For example, SOLIDEDIT only checks for a version when changing the color of an edge or face, and only to decide between displaying the Select Color dialog or requesting a color from the command line. For some commands, the version is checked to determine keyword options. For many commands, issuing (initcommandversion 1) before the command will simply cause it to run from the command line instead of using the dialog version, e.g., LAYER, BLOCK, INSERT. There is no official list of what will change in these commands if you explicitly initialize a version – you’ll just have to experiment.

How does (initcommandversion) affect commands that don't have versions?

Commands that don't use versioning are unaffected.  The command itself has to have been updated to support retrieving an initialized version in the first place.  Issuing (initcommandversion) prior to a command that doesn't check for versions is harmless and does nothing.

Why Should You Care About This?

As I said, command versioning was added specifically to support the Action Recorder and it should be mostly transparent in normal usage, however there are times when understanding it could be beneficial.

I recently received the following question from a customer, “Why does the fillet command end out of the fillet command after entering a radius? Shouldn't it continue back to the fillet prompt?" After asking for more information (since, yes, it should go back to the prompt after setting the radius), I found that he was invoking the FILLET command from within an AutoLISP function, like so:

(command ".fillet")

His objective was to simply start the FILLET command and then he would set the radius and pick the objects to be filleted, at which point the command would finish and the rest of the LISP would continue on. This worked for him prior to AutoCAD 2009 but when he ran it now, the FILLET command would start and as soon as he entered a radius value, it would exit the command. The reason it was failing now was that FILLET had been updated to support command versioning and it was affecting how FILLET responded when called in this manner.

The fix for this customer was to add one line to his existing LISP code to initialize the latest version of the FILLET command prior to calling it:

(initcommandversion 2)
(command ".fillet")

Here is an example of how that bit of LISP code behaves with and without the call to (initcommandversion):

This instructs FILLET to use the newest version of the command instead of the oldest version, which it would default to since it was being called from LISP (as I recall, we changed the “exit after radius” behavior back in 2000 for manual operations but retained the original behavior for script compatibility).

Understanding a little about command versioning and the (initcommandversion) function can help when trouble-shooting issues like this one and can give you a little more control over those commands that support versioning. For example, LISP and other automation tools now have a mechanism for accessing new behavior, like being able to invoke the Select Color dialog from a (command “.color”) LISP statement.

FLEXnet Licensing error: -125,147

It's been quite a while since my last post so I thought it would be good to start again with a topic that we are regularly asked about in support.

When clicking the Perform Diagnostics button in LMTOOLS you will see a FLEXnet licensing error which seems to indicate a problem with the licensing service:

 
 
This error is actually incorrect and occurs when an AutoCAD 2009 (or later) package license is being used. As an incorrect warning this error can simply be ignored.

To verify that the correct licenses are being issued by the server you can click the Perform Status Enquiry button on the  Server Status tab of LMTOOLS.

DFS Problems in AutoCAD 2010

Distributed File System (DFS) is a Microsoft implementation that allows Windows servers to organize distributed file shares into a Distributed File System. DFS allows shares in multiple locations to be logically grouped under one folder. Thus, rather than navigating to many disparate locations for individual folders, you could navigate to a single folder that contained all the folders from those different locations (that's an extremely cursory explanation – you can investigate it in-depth if want more info). Although Autodesk does not officially support using the DFS with AutoCAD and AutoCAD-based vertical products, it has been known to work properly in the past and many customers use DFS with our products.

We recently investigated reports that DFS was no longer working with AutoCAD 2010 (and AutoCAD-based verticals) and, after working closely with Microsoft Technical Support, a few great customers, and our own testers, we determined that we were actually looking at two separate issues:

1. Can't open a DFS folder from the File Navigation dialog in AutoCAD 2010

This problem was identified and has been corrected in Update 1 for AutoCAD 2010. If you are using an AutoCAD-based vertical product, you should apply the product Update that includes Update 1 from AutoCAD 2010. For most vertical products, that will also be Update 1 however, for AutoCAD Civil 3D, that will be Update 2.

2. Inability to open folders on a DFS share by double-clicking

With this problem, customers using our standard File Navigation dialog would double-click to open a folder on a DFS share but it would not open. We've mostly seen this issue on Vista SP2 and Windows 7 where Microsoft changed the folder to a link and the double-click action was no longer working to open the folders. This change affects all AutoCAD products. We expect to have a fix for this issue in a future release however, in the meantime, there is a workaround.

For file folders that won’t open using double-click, simply use the Open button on the File Navigation dialog instead.

We have communicated this workaround to several customers and it’s working as expected.

Product Support has documented the solution and posted it at the following link:

Distributed File System (DFS) Problems in AutoCAD 2010

Autodesk University: A Personal Retrospective

After a long and hectic week, another Autodesk University has come to an end. Although the attendance at this year's AU was apparently down from previous years, it really didn't feel like it. This year's AU had all the energy and activity of earlier conferences and I would have been hard-pressed to tell you if it had less attendees.

I taught two classes ("How to Get the Most Out of the Action Recorder" and "All Things Layers in AutoCAD"), presented one of the new AU virtual product clinics ("Online License Transfer in Autodesk 2010 Products"), did an interview for AutoCAD Exchange with Heidi Hewett, met many of our Subscription customers while manning the Subscription kiosks, and enjoyed the chance to meet and chat with some of our Platinum Subscription customers over lunch. All in all, it was another hectic, yet satisfying, week at Autodesk University. My MacBook Pro performed admirably for the 3rd year in a row and, with the exception of a couple technical and logistical issues between my two classes (when you only have 30 minutes between classes, it's not cool to rush to your next classroom only to find the previous class hasn't been dismissed yet), things ran without a hitch.

I was reading the survey results from my classes this year and was amused to see the following comment from an attendee, "He did well - I understand it's his first AU." Although I wasn't completely sure how many AUs this was for me, I definitely know it wasn't my first in the 17 years of AU conferences. After digging through my old files, I confirmed that this was my 12th Autodesk University over the last 14 years.

My very first AU was in 1996, at Navy Pier, in Chicago, IL – two years before I would be hired by Autodesk. At that time I had been writing articles for the solid (but, sadly, short-lived) AutoCAD Tech Journal quarterly magazine. I was approached by Miller Freeman editors (who also published CADENCE magazine) and was asked to teach a class at AU. My first AU class was "AutoLISP Programming for Professionals" where I focused on how to write user-friendly AutoLISP programs that anticipated the unpredictable nature of end-user interactions. I just dug out the original handout (14 pages - even then I couldn't keep it to recommended page limit) and, with few exceptions, the concepts could still be taught today. Between then and now, I have only missed two Autodesk University conferences: 1998 (I was a new Autodesk employee that year and wasn't able to attend) and 2005 (my AutoCAD development schedule just didn't permit the time that year).

I always enjoy AU because I get to meet so many of our customers. Every time I see someone with an AU badge in an elevator or outside the hotel – when I just need to breath actual air that doesn't come from casino filtration systems – I ask how the conference is going for them. Invariably, I get a positive response that usually includes a statement like, "I didn't think there was anything else for me to learn in xyz area but I have learned a lot this year." Excellent! That's why you come to AU and that's what makes it all worth the effort for both the teachers and the attendees.

Another one of the best parts of attending Autodesk University each year is the chance to spend time with my AU friends: people that I only see – once a year – at this conference. These are friendships that have developed over the course of the last decade (or more) and they are an important part of my AU experience. AU is our chance to catch up, commiserate, and talk shop for as long as our AU schedules will allow. So … to my good friends, dave espinosa-aguilar, Scott McFarlane, James Wedding, Alex Lepeska, and anyone else I'm forgetting right now: It was great seeing you last week and I look forward to seeing you again next year.

Were you in attendance this year, either live or at one of the virtual AU sessions? Let me know how it was for you?