Topic: Autolisp Shell Extension .Net version

[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.