Returns a string containing the name of the class or superclass. If the supplied argument is not an object, an empty string is returned. If no argument is supplied, OBJ_CLASS returns an array containing the names of all known object classes in the current IDL session.
A scalar object reference or string variable for which the object class name is desired. If Arg is an object reference, its object class definition is used. If Arg is a string, it is taken to be the name of the class for which information is desired. Passing a string argument is primarily useful in conjunction with the SUPERCLASS keyword.
Set this keyword equal to a named variable that will contain the number of names returned by OBJ_CLASS. It can be used to determine how many superclasses a class has when the SUPERCLASS keyword is specified.
Set this keyword to cause OBJ_CLASS to return the names of the object’s direct superclasses as a string array, one element per superclass. The superclasses are ordered in the order they appear in the class structure declaration. In the case where the class has no superclasses, a scalar null string is returned, and the COUNT keyword (if specified) returns the value 0. If SUPERCLASS is specified, the Arg argument must also be supplied.
Note: In order for OBJ_CLASS to determine the superclasses, the class specified in Arg must have already had its class definition loaded into IDL. If Arg is an object reference then IDL will already have the class definitions loaded. If Arg is a string classname, then you may need to ensure that the class definition is loaded. To avoid the overhead of creating an object, you can simply create a named structure of the appropriate class.
Note: Some IDL objects are subclassed from more generic IDL objects. You may see references to the generic IDL objects when using the SUPERCLASS keyword to the OBJ_CLASS function to get information on an object. You may also notice that the generic objects are not documented in the Object Class and Method Reference. This is not an oversight.
We have chosen not to document the workings of some of the generic objects from which IDL objects are subclassed because we reserve the right to make changes to their operation. We strongly recommend that you do not use the undocumented object classes directly, or subclass your own object classes from them. There is no guarantee that user-written code that uses undocumented features will continue to function in future releases of IDL.