acedGetArgs Global Function
struct resbuf *
acedGetArgs();
Retrieves arguments to requested external function.
Returns a pointer to a linked list of the arguments that AutoLISP has passed to the ARX application through an kInvkSubrMsg message. The acedGetArgs() function retrieves these arguments, allocates result buffers, and places the argument values in these result buffers. If AutoLISP has not passed any arguments to the application, acedGetArgs() returns a null pointer.
After calling acedGetArgs(), the ARX application can traverse the result-buffer list to retrieve and use the function arguments.
Unlike the result lists returned by other ARX library functions, the list returned by acedGetArgs() is managed by the ARX library, so the application does not explicitly have to release the list. (A call to MSITStore:D:\ObjectARX%202006\docs\arxref.chm::/Globals/AcUt/acutRelRb.htm" target="_blank" >acutRelRb() that specifies this list has no effect.) Applications needing data in the list should make copies of it.
Note In Release 14, entity data lists were treated specially by ads_getargs(). For an entity data list, the linked list of resbuf structures returned by ads_getargs() had no resbuf with type code RTLB at the head of the list and matching resbuf with type code RTLE at the end of the list to act as a bracketing "wrapper" pair indicating that the data was all within a single list. If the list was not an entity data list, then when a list was passed to ObjectARX, ads_getargs() returned a resbuf chain with a "wrapper" RTLB/RTLE pair.
This special treatment of entity data lists was not desirable - all lists should be treated the same by ads_getargs() (now acedGetArgs()) and ads_retlist() (now acedRetList()).
Another problem with the way Release 14 treated lists was that ads_retlist() always added an RTLB/RTLE "wrapper" pair. When passing a list back and forth between AutoLISP and ObjectARX, this caused the list to be repeatedly nested one level deeper in a set of nested lists. For example, if (list "a" "b") was passed to ObjectARX from AutoLISP, then returned to AutoLISP, then passed to ObjectARX, then returned to AutoLISP, the result would have been:
((("a" "b")))
but the original was simply:
("a" "b")
In AutoCAD 2000, the behavior of acedGetArgs() and acedRetList() has changed so that they treat all lists the same and in a fashion that does not alter the list during a round trip.
The rule that AutoCAD 2000 follows for acedGetArgs() is that if the data passed out to ObjectARX is a list, then there will be an RTLB/RTLE for each list nesting level. This is the way Release 14 treated non-entity data lists.
The rules AutoCAD 2000 follows for acedRetList() are that if the resbuf chain passed to acedRetList() is already a valid list (in other words, it has a "wrapper" RTLB/RTLE resbuf pair), then no RTLB/RTLE wrapper resbuf pair will be added. If the resbuf chain is not a valid list, and acedRetList() is returning the list to AutoLISP (as opposed to another ObjectARX program) then an RTLB/RTLE resbuf wrapper pair will be added internally (not to the actual resbuf linked list passed into acedRetList()) to make it a valid list. When returning the data to AutoLISP, acedRetList() must add an RTLB/RTLE wrapper to a resbuf chain that is not a valid list because AutoLISP cannot handle the data otherwise.
These rules apply to all data passed to ARX and obtained via acedGetArgs() and all resbuf chains passed to acedRetList(), so there is no more special casing just for entity data lists.
If you need to have the old Release 14 behavior, you can write a utility function that will add the extra RTLB/RTLE wrapper as Release 14 did. You can also write a similar utility function to strip the RTLB/RTLE resbuf wrapper pair off of entity data list resbuf chains returned by acedGetArgs().
Though these changes may require you to update your existing code, the new AutoCAD 2000 behavior is an improvement that allows easier maintenance and greater flexibility and versatility in the future.
Include Fileacedads.h |