Part I
Part II
Part III
Part IV
Part V
Part VI

To run code when an application loads you need to create a class that implements the IExtensionApplication interface.  I haven’t created a class in F# yet, and certainly not one that implements a specific interface, so I did what I always do when trying something new, I searched Kean’s blog.  And sure enough, he’s covered this very topic.

I don’t think mine varies much from Kean’s, other than I’m calling a function from another module instead of coding it all inline.  It didn’t start that way, but as the code grew it just made sense to refactor it and create a UI module.  I’ve also wrapped the call in a try block.  It’s not that I expect the code to fail on startup, but if it does, AutoCAD in a defensive maneuver against poorly written add-ons will simply not load an assembly that throws an exception in the Initialize method.  And if there is an error, it doesn’t display any messages.  So a try block is useful, especially when debugging.

   1: #light

   2:  

   3: namespace BobbyCJones

   4:  

   5: open Autodesk.AutoCAD.Runtime

   6: open BobbyCJones

   7:  

   8: type InitBOMTools () =

   9:   class

  10:     interface IExtensionApplication with

  11:       member x.Initialize() =

  12:         try

  13:           UI.InitBOMPaletteSet()

  14:         with

  15:           | _ as err ->

  16:             System.Windows.Forms.MessageBox.Show(err.Message) |> ignore

  17:         

  18:       member x.Terminate() =

  19:         ()

  20:   end

  21:  

  22:   

  23: module Init =

  24:   [<assembly: ExtensionApplication(typeof<InitBOMTools>)>]

  25:   do ()

One final note before I wrap up this series.  F# is very dependent on code order.  You can’t reference an identifier in a file prior to it being declared.  In the initialization module above, we couldn’t move the code

module Init =
    [<assembly: ExtensionApplication(typeof<InitBOMTools>)]
    do ()

to the top of the file, because it reference the InitBOMTools type and must come after the InitBOMTools declaration.  And not only is code order within a file important, but the compile order of files in a project is important.  As you can see in the image below, each module resides in it’s own file.  The init.fs file has to come after the ui.fs file, because the init.fs file references code inside the ui.fs file.  And the ui.fs file references code in the polyTools.fs file, so it must come after polyTools.fs.  The order of the files listed in Visual Studio is the order that they will be provided to the compiler.  Visual Studio allows you to sort the files after you create them as well as add new files above and below existing files.

Looking back at my original goals for this project, I am very happy with the outcome.  I have a working application that’s been in use for a couple of weeks now.  It was easy and very fun to write.  I took my original C# project of 430 lines of code spread over 7 files and reduced that to about 250 lines of code spread over 4 files.  That 250 number counts white space and comments, whereas the 430 does not, so the delta is even greater than what you see at first glance.

As a CAD manager I see myself using F# much more in the future.  It’s a great tool that fits well in the CAD world.