Topic: Adding net framework functionality to lisp

[GUIDO ROOMS]

I've got plans to add some net framework functionality to lisp through lispfunctions.
Some examples: string manipulation, messagebox functions, registry functions, filedialogs etc...
Only, I don't know if this isn't going to be too slow...

Does anyone here  have experience doing this?
tia

[BlackBox]

Nothing schmancy, mostly from when I first started learning .NET API... Probably needs a lot of streamlining... But as some examples:

CapsLock, NumLock, and ScrollLock

GetOwner

NetLoad, and Dll

vla-SetActivePageSetup

LayoutListSelected


Also, if you're going to code LispFunction Methods, be sure to cull Gile's 'LispException Classes' - very helpful (cheers Gile)!

HTH


[Edit] - Forgot this one too:

vla-get-ViewAnnoScale

... And at one point, I started creating a LispFunction for most (all?) of the common, single-function LAY* Commands (i.e., LAYLCK, LAYFRZ, etc.). Don't think I ever finished those though.

[GUIDO ROOMS]

Thanks for the reply, blackbox.

I've had a look at the examples you mention.
It's mainly things like those that I'm planning to to.
Some functions could of course be written directly in lisp, but that's a lot more work.

[BlackBox]

What sort of functions are you wanting to do?

[GUIDO ROOMS]

Basically, a number functions that are missing in lisp or are more work to implement there:
strings, parsing, math, messageboxes, directories, files, registry, users, some dialogs for user input, etc...

My only concern is speed. That's what I was asking about in my original post. Functions done directly in lisp will probably run faster than methods in the net framework called through lispfunctions. A bit like going round the back when you've already opened the front door.

But the last option saves a lot of work. Calling String.Split() through a lispfunction is less work than rolling your own in lisp... Getting a user string using an InputBox instead of using DCL... Calling Path.Combine()... To name just a few I'm thinking of right now.

Great pity that autolisp is but a sandbox when compared to common lisp. Otherwise I'd simply write everything in it. Also, I don't want to invest too much time in autolisp. I've got the impression that autodesk wants to kill it off asap. Let's hope I'm wrong there.

Thanks for your interest.

[BlackBox]

Firstly, all LISP functions (LispFunctions) are coded in either .NET, or ARX, AFAIK... What makes LISP so slow by comparison, is their incremental Transaction calls to Database, etc. each time a function is called. How one codes things has more impact on the speed of the code than the source code itself (as a generalization).

That said, don't fret the rumors of LISP going away... They've been spread for years, and I've seen little to show that a serious priority for Autodesk. More likely, they'll continue to not enhance LISP API, and enhance .NET API, etc. so that eventually it dies off through attrition.

If you plan on using LISP, or would benefit from the LispFunctions you're after... Code them, use them, and share them (if you can).

http://www.cadtutor.net/forum/showthread.php?82314-Entity-Processing

Cheers

[exmachina]

Maybe this will interest you:

http://wiki.mcneel.com/developer/doslib

DOSLib, is a library of AutoLISP-callable functions that provides a variety of Windows operating system capabilities to AutoCAD. Written as an AutoCAD ObjectARX application, DOSLib extends the AutoLISP programming language by providing the following functionality:

    Drives: Check for drives, change between drives, and check available disk space.
    Paths: Manipulate path specifications.
    Folders: Create, rename, remove, select, and change folders. Return special operating system folders.
    Files: Copy, delete, move, rename, and select files; get directory listings, search and find multiple instances of files, and change file attributes.
    Print: Get and set default printers, and spool print files.
    Configuration: Manipulate Windows-style initialization (INI) files, and access the Windows Registry.
    Processes: Run internal OS commands or other programs.
    Interface: Get strings, integers, reals, and lists from the user. Display Windows message boxes, progress meters, and splash screens.
    Strings: Tokenize strings, extract characters, find characters, insert, remove, and replace characters, and trim characters.
    Math: Trigonometric calculations, vector manipulation, statistical analysis, and more.
    AutoCAD: Save all and close all open files. Preview drawings and list xrefs.
    System: Get system information, sort lists, change the system date and time, manipulate the keyboard, and play sounds.

[It's Alive!]

been a while since I've played with this, but you can have a look here for some examples

http://www.theswamp.org/index.php?topic=11921.msg164100#msg164100