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.

[It's Alive!]

My point about barfing on the screen is NOT using acutPrintf to toss messages on the screen. It's much better to give the programmer the choice whether to display the message.

Why call a last-error function when you can just include the details in the result? IMHO returning nil is not adequate especially in items like SQL commands where there could be any number of reasons a call could fail AND where there is the potential to recover.

It's exactly like the .NETs PromptResult, you get the status, keyword and data all nice and packed in a struct. 

[It's Alive!]

BTY, I know you didn't printf your messages.... but pErrorRb leaks in your ARX version and don't release the result of acedGetArgs() 

[It's Alive!]

This is the first time I looked at your ARX code, and you have handled things nicely  :kewl:

[pkohut]

BTY, I know you didn't printf your messages.... but pErrorRb leaks in your ARX version and don't release the result of acedGetArgs() 

The point of the routine is so an application can get the error code and determine what to do next. Typical error handling. The calling application decides if it wants to print the string message to the screen. As far as finding the leak, thanks.

[It's Alive!]

Well what we ought to, do is get feedback from the lisp community on how best to handle this. I'm kind of warming up to the last error call after I've seen how you did it.

[pkohut]

This is the first time I looked at your ARX code, and you have handled things nicely  :kewl:

Actually, the only reason I post code is so others can look, critique, and learn.  Unfortunately, there is seldom any dialog, and the time spent working on the project ends up being wasted. Finding an error in my code and reporting it is cool with me. Telling me I implemented something stupidly would be cool too. Try sitting through code review where your peers are ripping a class you wrote, line by line, then tells you to rewrite the class. What I'm getting at is nobody learns in a vacuum, I want to teach and be taught, and value someone critiquing or shredding my code more than getting accolades.

[Kerry]

Actually, the only reason I post code is so others can look, critique, and learn.  Unfortunately, there is seldom any dialog, and the time spent working on the project ends up being wasted. Finding an error in my code and reporting it is cool with me. Telling me I implemented something stupidly would be cool too. Try sitting through code review where your peers are ripping a class you wrote, line by line, then tells you to rewrite the class. What I'm getting at is nobody learns in a vacuum, I want to teach and be taught, and value someone critiquing or shredding my code more than getting accolades.

Paul, I don't have the skill to constructively rip you code apart.
Please be comforted though by the knowledge that your contributions ARE appreciated and will be accessed well into the future.

Best Regards

[Kerry]

BTY, I know you didn't printf your messages.... but pErrorRb leaks in your ARX version and don't release the result of acedGetArgs()  

The point of the routine is so an application can get the error code and determine what to do next. Typical error handling. The calling application decides if it wants to print the string message to the screen. As far as finding the leak, thanks.

Well what we ought to, do is get feedback from the lisp community on how best to handle this. I'm kind of warming up to the last error call after I've seen how you did it.

Personally I don't think the methodology will matter to most customisers trying to access your libraries.
The important thing will be that it is documented .. somewhere other than the ARX source.

The quantum or errors I'd expect will be minimal
Most would be garbage in garbage out situations,
followed by user selection errors (ECS or ENTER misuse)
followed closely by assertion traps ( files, datatypes, range values, etc),

...  allowing the user (calling function) to handle the error is critical ... the mechanism provided is just mechanics.