Topic: Autolisp Shell Extension .Net version

[pkohut]

Here is a .Net version of the program from http://www.theswamp.org/index.php?topic=33994.0.

To the user, the only differences are environment variable expansion is not implemented for the application name, and return values from functions are in a list. For the .Net version handles and strings returned by the functions are wrapped in a list. The function parameters though do not want handles or strings in a list. So when passing a handle be sure to (car) it. This sample should give you an idea.

Code: [Select]

(setq handle (openshell "c:\\windows\\sysetem32\\cmd.exe" "\c sort")) ;; return nil on failure, an int in a list otherwise
(setq handle (car handle))
(writeshelldata handle "Once\nupon\na\ntime\n...\nzzz")
(setq sResult (readshelldata (car handle)))  ;;
(closeshell (car handle))
(princ (car sResult))(princ)
It has been a couple years since I wrote any .Net code, and maybe 3 or 4 years since I wrote anything in .Net for Autocad. Doing this exercise came away with the following tidbits.

1. Took 5 hours and 15 minutes to implement (not that I was purposely keeping time).

2. Wasted about an hour trying to get the commands to run in Autocad. Problem turned out to be having "Copy Local" to true for AcDbMgd and AcMgd references.

3. Wasted about an hour looking up ResultBuffer issues for the [LispFunction] attribute. Luckily ran across this link, http://forums.autodesk.com/t5/NET/Return-type-of-object-is-LispFunction-now-fails/m-p/2217766/highlight/true#M10052

4. Wrote 2 versions as a standalone app last night (not part of the 5h15m time period). The first version was pretty much a 1:1 conversion with DllImports up the, and lots of ugly code. Then I found a reference to the System.Diagnostic.Process api and the second version using it took like 20 minutes to write.

5. How are RTNORM, RTERR, RTNONE, RTLONG, etc. handled in .Net. Is there something to import? I just grabbed the items in adscodes.h and put them in ResultCodes.cs, but this seems heavy handed.

6. When dealing with ResultBuffers, is it customary to convert them into array prior to working with their contents?

7. Dealing with the ResultBuffers took bit of code thrashing, and it was easily 2 hours to write the public ResultBuffer OpenShell(ResultBuffer args) routine. After that each one was simple and took just a couple minutes.

8. Whole lot less boiler plate code to write in C# and faster to code (when not dealing with learning issues).

[It's Alive!]

#5
look for the LispDataType enum

#6
I just do this if it's a small app
List<TypedValue> ArgsList = new List<TypedValue>(Args.AsArray());

esle I like to use a modified version of TT's TypedValueList
http://www.theswamp.org/index.php?topic=14495.msg186823#msg186823

[pkohut]

#5
look for the LispDataType enum

#6
I just do this if it's a small app
List<TypedValue> ArgsList = new List<TypedValue>(Args.AsArray());

esle I like to use a modified version of TT's TypedValueList
http://www.theswamp.org/index.php?topic=14495.msg186823#msg186823

Very good, knew there had to be a elegant way to do that.

[xsfhlzh]

Rewritten version of mine
http://bbs.mjtd.com/dispbbs.asp?boardid=33&Id=79849&page=1&star=1#36794

[pkohut]

Rewritten version of mine
http://bbs.mjtd.com/dispbbs.asp?boardid=33&Id=79849&page=1&star=1#36794

I'm not a proficient .Net programmer, but I had issues returning some ResultTypes. In the end, for compatibility reasons, I decided to just return a ResultBuffer or null. Not what I wanted to do, but it should work 2007 - 2010. Refer to this post for more details http://forums.autodesk.com/t5/NET/Return-type-of-object-is-LispFunction-now-fails/m-p/2217766/highlight/true#M10052

Happy testing 

[It's Alive!]

Right, there where issues with the return types in a couple of  Acad versions.
I found it best to return a ResultBuffer to maintain compatibility

[xsfhlzh]

Rewritten version of mine
http://bbs.mjtd.com/dispbbs.asp?boardid=33&Id=79849&page=1&star=1#36794

I'm not a proficient .Net programmer, but I had issues returning some ResultTypes. In the end, for compatibility reasons, I decided to just return a ResultBuffer or null. Not what I wanted to do, but it should work 2007 - 2010. Refer to this post for more details http://forums.autodesk.com/t5/NET/Return-type-of-object-is-LispFunction-now-fails/m-p/2217766/highlight/true#M10052

Happy testing 

I test it use 2008/10,it work well
Comnand: (mylisp1 T)
T

Command: (mylisp1 nil)
nil

[xsfhlzh]

Right, there where issues with the return types in a couple of  Acad versions.
I found it best to return a ResultBuffer to maintain compatibility

I think it work well :
return new TypedValue((int)LispDataType.T_atom, true)

[pkohut]

Right, there where issues with the return types in a couple of  Acad versions.
I found it best to return a ResultBuffer to maintain compatibility

Ya, it's a stupid work around that shouldn't be, it can potentially break lisp code that depends on the results being returned as a different type.

edit: If my .Net skills were better and had code that is dependent on LispFunctionAttribute, I'd be looking into rolling my own version of LispFunctionAttribute that had the correct behavior and be done with incompatibility concerns and issues. At its core the code is probably pretty simple. 

[It's Alive!]

I did it for Bricscad 

[It's Alive!]

Ya, it's a stupid work around that shouldn't be, it can potentially break lisp code that depends on the results being returned as a different type.

I wouldn't call it stupid, just necessary given the circumstances 

[pkohut]

I did it for Bricscad 

Did it have the same error? You should port it to AC and give a little tut on writing custom attributes.

[pkohut]

Ya, it's a stupid work around that shouldn't be, it can potentially break lisp code that depends on the results being returned as a different type.

I wouldn't call it stupid, just necessary given the circumstances 

Ok, fair enough. It's "studid" that a workaround is necessary. Semantics 

[It's Alive!]

Actually, I kind of like returning lists in all cases. I've been doing this for quite some time via .NET and ARX.
For example in my SQLite routine, I return (T . Success) , (NIL . Exception) and (DATA).
This way, I have a choice whether or not to pass the exception message to the end user or handle it. Much better than barfing all over the screen...
At some point, I may add an error codes, (NIL ErrCode Exception).

[pkohut]

Actually, I kind of like returning lists in all cases. I've been doing this for quite some time via .NET and ARX.
For example in my SQLite routine, I return (T . Success) , (NIL . Exception) and (DATA).
This way, I have a choice whether or not to pass the exception message to the end user or handle it. Much better than barfing all over the screen...
At some point, I may add an error codes, (NIL ErrCode Exception).

If you control both ends of the pipe then you're free do as you please. I may not be getting the big picture with your example, but it seems over engineered. If I understand correctly, the routine can return 1 of 3 different types of state, and you're looking to add a forth?  If the purpose of the routine is to retrieve data, then return the data on success, nil otherwise. Have another routine the user can call to get the error if nil had been received. Simple.  If you don't know how to handle errors and exceptions to keep your own code from "barfing all over the screen", what makes you think others should use it too.