Topic: Common, Simple Commands | LISP -> .NET?

[BlackBox]

Being new to .NET development, I'm curious to know how others handle common, simple commands that are typically written in AutoLISP / Visual LISP and loaded via acaddoc.lsp as opposed to a single netload call during acad.lsp?

LISP Example:

Code: [Select]

(defun c:Q  ()
  (princ "\rMBUTTONPAN = ")
  (if (= 1 (getvar 'mbuttonpan))
    (setvar 'mbuttonpan 0)
    (setvar 'mbuttonpan 1)))

.NET Example:

Code: [Select]

    <CommandMethod("Q")> _
    Public Sub Q()
        Dim ed As Editor = Application.DocumentManager.MdiActiveDocument.Editor
        If Application.GetSystemVariable("mbuttonpan") = 1 Then
            Application.SetSystemVariable("mbuttonpan", 0)
            ed.WriteMessage(vbLf & "MBUTTONPAN: OFF ")
        Else
            Application.SetSystemVariable("mbuttonpan", 1)
            ed.WriteMessage(vbLf & "MBUTTONPAN: ON ")
        End If
    End Sub

Do you leave your code in LISP and load for each drawing, or do you recommend bringing everything over to a .NET project (C#, or VB), and netload once with acad.lsp (or registry?) and be done with it throughout your entire session?

I'm doing a lot of tutorials. While not practical for all circumstances, at least from a learning standpoint, I think it might be helpful for me to undertake the process of "figuring out" how to write the code for each of my routines in .NET. Obviously concepts like transactions, etc. are new to me. Afterall, I'm the author of the plethora of LISP code to begin with.

I'm interested in your feedback, and any suggestions you might have for project organization (separate, or grouped CommandMethods under one class), and also in how you go about demand loading (registry?), etc.

I hope that I have been specific enough in my questions, if not please let me know.

I am using Visual Studio 2010 Express, with Land Desktop 2009, and Civil 3D 2011, focused more on migrating to C3D from LDC.

[dgorsman]

The simple stuff I keep in LISP, and am not planning on migrating it to dotNET.  Easier to work with, easier to get help with in case I get run over by a bus (we're having a hard enough time getting additional CAD Support hires without including dotNET abilities).  dotNET is being applied for new things that hit a minimum break-even point in complexity vs. return, e.g. dialogs with images, some complex XML data handling.  That way its no different than any other out of file (defun...) reference.

For now, I'm not doing *any* command functions in .NET, just support functions for LISP, and its all demand-loading through the registry.  Utilities are either loaded for the session or the drawing, depending on what they do.  Large scale applications with periodic use will be command-invoked (I'm evaluating using a bootstrap loading mechanism on the command-invoke to update the local DLLs before loading e.g. command call invokes loader function, which updates DLLs, then loads them).  Eventually I will be including command definitions but only for work that is dotNET front-to-back, for the sake of not ending up half-bald from pulling out hair.

[Jeff_M]

I have lots of old lisp which sits on my HDD and I rarely use any more. When I made the jump to .NET I started out by converting some often used lisp routines to .NET, but that's as far as I went...maybe a half dozen or so, all the rest are kept as lisp and loaded as needed. I have not added new lisp code in probably 3 years or so (at least not that I can recall), rather all new commands and functions are done in .NET and loaded via the registry.

Using Visual Studio 2008 Express C# for C3D2009-2012.

[BlackBox]

Guys, thanks for your feedback!

I'm still new enough that I honestly don't quite understand how to do most of what you shared, but I know enough that I'll be revisiting this thread for ideas as I progress.

I've got to run now... but I'd like to thank you both for your time.

Cheers! :beer:

[BillZndl]

Funny you should ask.
Just yesterday I played with code that does what dos_find did for me in finding all *.bak files on the drive.

Code: [Select]

using System.IO;

namespace FileMethods
{
    public class FileMethodLibrary
    {           

        public static string[] FindBackupFiles()
        {                       
               
            string[] filepaths = Directory.GetFiles(@"J:\", "*.bak", SearchOption.AllDirectories);               
               
            return filepaths;
        }
    }
}

Don't know if it's any faster because of all the subfolders but now it's something I have control over.
I also added a form with listbox so I could visually pic what files I didn't want to delete and
I'm sure I'll be adding more features.
For now I netload it at startup and then fire the program as a command with the name from the command method.

[Jeff H]

Also that is something you could do on another thread or as seperate .exe

[BillZndl]

Hmmm,
just finished a tutoral on backgroundWorker threads only to see it finished with this comment:
"Threads aren't always useful, such as for I/O operations" 
I noticed it wouldn't fill my list box for some reason.
Oh, well it was a good exercise and I learned something. 

[dgorsman]

Can't multi-thread anything that interacts with AutoCAD.  For example, you could spin off threads that pre-cache data from a massive database of point data, but pushing the values into block attributes could not be done that way.