January 13, 2012

Using Log4Net with Visual Lisp

Filed under: AutoCAD,Development — Tags: , , , — Darrin Maidlow @ 1:07 pm

If you’ve worked with me or talked technical with me in the past there is a good chance you area already very aware that I love .  There is also a really good chance that you know I still have a special place in my heart for .  Not only did I spend what may have been the “best years of my life” buried in VLIDE (or hey, maybe all those 30+ hour days and passing out under my desk were the best years of my life? =)) , I still firmly believe that Lisp is one of the most effective way to bang out even a relatively complex operation in AutoCAD when it comes to data manipulation.  ObjectARX (both original and .NET) is great – but the time and effort overhead is pretty high when you just need to bang out a quick routine.

<3 Visual Lisp

Even the quick routines need a little error handling and logging can make a huge difference in documenting the results or diagnosing problems.  Keep Reading

October 28, 2011

Control Active AutoCAD Ribbon Tab from Visual Lisp – RibbonNinja!

Filed under: AutoCAD,Development — Tags: , , , — Darrin Maidlow @ 5:18 pm

A friend asked me recently if there was some way to control the active ribbon tab from a macro.  After a little bit of digging I could not find any lisp or command line command that would do this.  ObjectARX however does provide the functionality I needed so I decided to whip something together in c#.  I’ve named it RibbonNinja – because lets face it, ninjas are awesome and should play a much larger part of everyday life.

How’s it work?

Attached is a zip file that contains the dll.  To use this simply netload the dll into your AutoCAD session and issue the all powerful RibbonNinja lisp call.  It takes a single string parameter that is the name of the tab you want to activate.  If it finds and activates the tab it will return T, if not it returns nil.  For example given the following AutoCAD ribbon:

mapribbon

Issuing the following lisp statement will change the active tab from “Map Setup” to “Analyze”.  Then it would switch to “Home"

   1: (RibbonNinja “Analyze”)
   2: (RibbonNinja “Home”)

This code is not case sensitive.  If its even possible to have multiple menus within AutoCAD with the same spelling but in different cases you’re probably S.O.L. and it will always choose the last one.  I’ve assumed unique tab names.

This dll has been compiled to work against AutoCAD 2012.  It will support both x86 and x64 versions.  It should also work on any AutoCAD vertical (i.e AutoCAD Map, Civil, ADT etc etc).  If you get the following  error when you try to netload the dll we have one last change to make:

Cannot load assembly. Error details: System.IO.FileLoadException: Could not load file or assembly ‘file:///C:\Program Files\Autodesk\AutoCAD 2012 – English\RibbonNinja.dll’ or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0×80131515) File name: ‘file:/// C:\Program Files\Autodesk\AutoCAD 2012 – English\RibbonNinjadll ‘ —> System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch.

Please read and try the following posts.  .NET 4.0 is “protecting” us so we need to fix that.  First you can try and “unblock” the dll following the steps outlined on .  If that doesn’t work for you again shut down AutoCAD and edit your acad.exe.config file as explained by Kean Walmsley on .  Remember to run notepad or whatever editor you’re using as an administrator – or you will get permission errors when you try to save the config file.

Turn up the nerd

For those of you more technically inclined the source is pretty simple once you figure out the mess of  references that are needed:

   1: [LispFunction("RibbonNinja")]
   2: public TypedValue GoNinjaGoNinjaGo(ResultBuffer lispArgs)
   3: {
   4:     //check the params
   5:     Editor ed = Autodesk.AutoCAD.ApplicationServices.Application.DocumentManager.MdiActiveDocument.Editor;
   6:     if (lispArgs == null)
   7:     {
   8:         ed.WriteMessage("\nIncorrect number of arguments.  Expected 1 parameter, received none\n");
   9:         return new TypedValue((int)LispDataType.Nil);
  10:     }
  11:  
  12:     if(lispArgs.AsArray().Length != 1)
  13:     {
  14:         ed.WriteMessage("\nRibbonNinja - Incorrect number of arguments.  Expected String - tab keyboard shortcut\n");
  15:         return new TypedValue((int)LispDataType.Nil);
  16:     }
  17:     //get the tab name
  18:     String tabKey = Convert.ToString(lispArgs.AsArray()[0].Value);
  19:  
  20:     //get the ribbon
  21:     Autodesk.Windows.RibbonControl ribCntrl = Autodesk.AutoCAD.Ribbon.RibbonServices.RibbonPaletteSet.RibbonControl;
  22:     
  23:     //find the custom tab using the Id
  24:     foreach (RibbonTab tab in ribCntrl.Tabs)
  25:     {
  26:         //is this the one we're looking for?
  27:         if(tab.AutomationName.ToUpper() == tabKey.ToUpper())
  28:         {
  29:             //yup - get it active and bail. weeeeee
  30:             tab.IsActive = true;
  31:             return new TypedValue((int)LispDataType.T_atom);
  32:         }
  33:     }
  34:     return new TypedValue((int)LispDataType.Nil);
  35: }

Thanks for the challenge Shawn!  Here is your shiny new

.  Feel free to use this commercially – I always appreciate links to my posts in exchange !  If you have an AutoCAD project that you could use some help with – please feel free to contact me via !

p.s. Two posts in two days.  that’s crazy talk I tell ya!

Update 2012.04.13 – Shawn Dillon sent me a copy of his tabs.lsp file. I’ve included it here Tabs.lsp

August 9, 2011

Hacking Visual Lisp IDE to be a little more awesome!

Filed under: AutoCAD,Development — Tags: , — Darrin Maidlow @ 11:12 am

Even though it’s the year 2011 and is available in all its glory for .NET I still spend a lot of time in the IDE (VLIDE).   While ObjectARX is powerful and full of awesome, it comes at a cost of a lot of overhead to setup a project, add all the needed references, heck even compiling / debugging is a huge pain in the ass in comparison to Lisp.  Lisp is still hands down the most efficient way to do most batch modifications within an AutoCAD session for those who have made the time to learn it.lispide

There are a couple of problems with Visual Lisp right now though.  One of my biggest complaints about the VLIDE is the default colors.  The high contrast white background is an eye killer.   The IDE is configurable though and we’re given full a 16 bit color palette – with which I was able to configure a color scheme that was more to my liking.   If you start Visual Lisp, go to the Tools menu and choose Window Attributes you are presented with the dialog that should let you configure your colors.   Before opening this configuration dialog select a code window in Visual Lisp to modify. Set the properties accordingly. If you are happy with the colors when you press Ok on the dialog you will be prompted to “Use current as EDITOR prototype?”. Clicking yes here will update you editor prototype, resulting in future windows using these defaults.

One key limitation here is that on x64 editions of AutoCAD this dialog is broken.  You may also see the following error when you attempt to close the dialog:

; warning: unwind skipped on exception
; error: Exception occurred: 0xC0000094

**Update May 11th 2012 – This appears to have been fixed in AutoCAD 2013 x64.  Hurray!

It seems that Autodesk has let this code go to some extent. I’ve seen a number of of  people mentioning the unwind error.  This is a shame and partly why I’m writing this post!  First off – if you have an x86 release of AutoCAD you are in luck.  You can configure your IDE no problem using the UI.  For you x64 users, all is not lost.  Lucky for us Visual Lisp saves all this configuration information to a text file named VLIDE.dsk.  On my Vista x64 machine its found in the following locations:

AutoCAD 2006 – C:\Users\dmaidlow\AppData\Roaming\Autodesk\AutoCAD 2006\R16.2\enu

AutoCAD 2009 – C:\Users\dmaidlow\AppData\Roaming\Autodesk\AutoCAD 2009\R17.2\enu

AutoCAD 2010 – C:\Users\dmaidlow\AppData\Roaming\Autodesk\AutoCAD 2010\R18.0\enu

AutoCAD 2011 – C:\Users\dmaidlow\AppData\Roaming\Autodesk\AutoCAD 2011\R18.1\enu

AutoCAD 2012 – C:\Users\dmaidlow\AppData\Roaming\Autodesk\AutoCAD 2012 – English\R18.2\enu

These paths should be the same or similar on Windows 7.

If you open up this file you’ll see a large list of dotted pair lists full of settings.  The one I’m most interested in here is the *editor-sample-window property.  This is the “default” configuration to use when opening a lisp file.

   1: (*editor-sample-window* (:AUTOLISP :FGC 16777215 :BGC 0 :LXC T :CLV #40(nil nil 16711935 nil nil nil 16776960 nil 32768 nil 32768 nil 8421376 nil 8388736 12632256 8388736 12632256 8388736 12632256 255 nil 128 nil 8388608 nil 128 nil 12632256 nil 16777215 0 16777215 16750899 16777215 255 nil 8388608 nil 16776960) :TW 4 :LM 10))

Two values of importance are FGC (foreground color) and BGC (background color).  I was having a hard time finding a color wheel that did integer based color codes – but you can convert your favorite hex color codes to decimal ().  The next bit is a little ugly.  Within the :CLV property we have a list.  This list is basically a list of 16 bit integers containing a color code of the foreground and background color of each window property.  If the color is set to nil – it is transparent.  This list appears to be in the order in which the properties are displayed within the UI:

  • :LEX-SPACE
  • :LEX-STR
  • :LEX-SYM
  • :LEX-NUM
  • :LEX-INT
  • :LEX-REAL
  • :LEX-COMM
  • :LEX-COMM1
  • :LEX-COMM2
  • :LEX-PAREN
  • :LEX-SPEC
  • :LEX-SPEC1
  • :LEX-UNKN
  • :WINDOW-TEXT
  • :WINDOW-SELECTION
  • :ERROR-HIGHLIGHT
  • :INPUT-ZONE
  • :CONSOLE-MESSAGE

TW and LM contain the tab width and left margin respectively.  So go wild editing these values and configure your new IDE!  Keep in mind when editing the Visual Lisp settings using the UI, the vlide.dsk file is not saved  until AutoCAD is shutdown cleanly.  If AutoCAD crashes, you will lose your configuration.  If you would like to try out my IDE settings – I’ve attached a zip file containing  a copy of my .DSK file.  I also recommend you make a backup of the .dsk file before you start tinkering.

Now, if only I could figure out some way to build a vlx file from the command line so as to integrate it into my automated build system..

Update!

For those of you who don’t read the comments – Dennis Hill was cool enough to share his digging into the DSK file and also his IDE colors which I’ve been running for a week or so now.  Take a minute to read the comments and check out his color scheme.  Thanks Dennis!

Technorati Tags: ,,

March 22, 2011

Debugging COM DLL files in AutoCAD x64 and Visual Studio

Filed under: AutoCAD,Development — Tags: , — Darrin Maidlow @ 12:19 pm

While attempting to work out some x64 specific kinks in some of the COM code that is being migrated to .NET I hit a pretty annoying wall.  Well, it was actually a series of small walls (probably around knee high)  that kept tripping me…

In this post, I’m working on a problem that is pertaining to a 64 bit version of AutoCAD loading a COM enabled .NET assembly – however this information should apply to any x64 executable calling any x64 COM assembly.   Replace AutoCAD with <YourApp.exe> and you should be good to go =)

The first thing I did was to ensure each of the projects had been set to build for  “ANY CPU”.   This got the ball of fun rolling.   We have a VLX which instantiates the COM class using vlax-get-or-create-object.  When called this would constantly return nil.   Of course this all works just peachy when running an x86 build of AutoCAD.   At this point my breakpoints would appear in Visual Studio as disabled and would happily inform me that “The breakpoint will not currently be hit”.

This usually results when the incorrect DLL is being loaded, or when the PDB file is missing.   Once Visual Studio is running in debug mode you can bring up the Modules window from the Debug/Windows/Modules menu.  This should show you all the assemblies involved in the current session as well a bunch of other information including their paths.  The assembly in question was not listed here – so at this point I’m assuming that Windows cannot find the dll.

Junk in the Registry

I am now thinking that I have orphaned and duplicated types and CLSIDs in the registry, likely pointing to other builds of the dlls.   If the GUIDs for the classes or types changed you end up with a lot of junk in the registry.   I don’t trust those registry “cleaner” apps and in the interest of keeping my OS working – I chose to manually search out and nuke all the registry references manually.  This can be done by searching both for your assembly’s type name, and COM exposed class names in regedit.  A lot of this was done in the HKEY_CLASSES_ROOT root.  After all of that the problem still exists..

Wow6432Node Registry Keys

Registry keys were a two part problem. After dealing with the junk in the registry, I found I also had to deal with the x86 .   DraftLogic has been until this point limited to x86 architecture as a result of  the VB6 code not being x64 friendly.   As a result of this, all of the needed keys had been placed in the WOW6432Node of the appropriate software registry sections.   This was the easiest wall to find and hop over.  Unfortunately, this also didn’t solve the problem.

Improperly Registered Assemblies-thanks for nothingVisual Studio

So the next and fortunately final problem turns out that Visual Studio 2005/2008 (unsure about 2010)   Turns out the last piece of the solution is pretty simple – couple changes to the project.  What’s happening is that Visual Studio is running the x86 build of regasm.exe to register the assemblies on run, probably because Visual Studio is an x86 app itself.  This results in all kinds of x64 hating… To solve this we have to change two things in the COM enabled projects.

First though, I created a new build configuration called x64 so these changes would not affect in my ANY CPU configuration – which will be used to build my shipping assemblies.  It is also important to note that this problem is MOSTLY only a problem when running code from the IDE.  Assemblies installed and registered using an installer should not have this problem if the installer takes into consideration the “bitness” of AutoCAD (or any application calling your COM enabled dll).  ie.  Installshield asks the user on install what “bitness” of AutoCAD they are using, and the assemblies are registered as needed.  It may also be possible to register an assembly using both the 32 and 64 bit versions of regasm – but I have not tried this.

So with the new x64 configuration created I edited the properties of each COM enabled project  I unchecked “Register for COM interop” and added a post-build event command line of:

%Windir%\Microsoft.NET\Framework64\v2.0.50727\regasm $(TargetPath) /register /codebase /tlb

This would ensure that my COM enabled assemblies were properly registered for use by 64 bit  applications.

After all that, my breakpoints were finally hit, and I could actually start working out the x64 specific bugs. Too bad we couldn’t have moved this to ObjectARX.NET instead – then this would have been a non-issue =)  In retrospect, each of these problems were a contributing factor and each needed to be resolved. 

Hopefully if you are facing a similar issue this post helps you get over at least a couple of the walls!

February 14, 2011

Debugging Visual Lisp and ObjectARX.NET Together

Filed under: AutoCAD,Development — Tags: , , — Darrin Maidlow @ 12:22 pm

I encountered the following error when trying to debug a new ObjectARX .NET assembly using loaderlockwasdetected

Attempting managed execution inside OS Loader lock. Do not attempt to run managed code inside a DllMain or image initialization function since doing so can cause the application to hang.

This error would occur 95% of the time and pretty much took out AutoCAD each time it happened.  Fortunately this can be disabled manageddebuggingeceptionspretty easily within Visual Studio (I’ve tried both VS 2008 and VS 2010).   In Visual Studio bring up the exceptions dialog from the Debug / Exceptions menu (or via the keyboard shortcut Cntrl D+E). 

Expand the “Managed Debugging Exceptions” section and uncheck “LoaderLock” in the “Thrown” column.  Next time you start AutoCAD from Visual Studio and load Visual Lisp you should no longer get this exception and you should be merrily debugging away.

Powered by WordPress

Switch to our mobile site