The Source Processor is a Python script that is executed every time a MAXON API ALIASES framework or plugin is build. The script checks the code for certain programming errors and creates additional code.
If a project file is created with the Project Tool, the script is automatically added to the build process. It is not needed to run it manually. The output console of the IDE will display which file or files are parsed and what errors the script has detected.
To debug a program and to follow the program flow it is useful to print a statement to the IDE's console window. This can easily be done with DiagnosticOutput().
For more debug functions see Debug and Output Functions and Debugging.
The MAXON API ALIASES includes a sophisticated error system. This system allows functions not only to return arbitrary values but also dedicated error objects. Such an error object contains information on what exactly went wrong within the function. For an overview see Error Handling.
This simple code snippet accesses the name of the host machine:
maxon::Application::GetMachineInfo() returns a DataDictionary that includes various system data. To access the data one can use maxon::DataDictionaryInterface::Get(). This function does not return a primitive value but a maxon::Result object. Such a maxon::Result object contains either the return value or an error object.
It is possible to manually handle the maxon::Result object. See also Error Result.
The preferred way of handling errors is to use various attributes. These attributes can be used to handle the program flow in the case of an error. E.g. ifnoerr() executes the given code only if no error occurred.
Within a function that returns a maxon::Result one can return either a valid return value or an error object. Such an error object can be one of many build-in error types. See Error Types.
Within such a function one can also return the error returned by a sub-function. This is automatically done by using the attribute iferr_return. To use this macro one must prepare the scope using iferr_scope.
The attribute iferr_scope_handler allows to define some code that is invoked when an error is detected with iferr_return.
Every plugin that uses the classic API (linking to cinema.framework) must implement the global functions PluginStart(), PluginMessage() and PluginEnd(). This is typically done in a main.cpp file.
PluginStart() is used to register classic API plugins. PluginMessage() can receive various global messages. PluginEnd() is used to free data before the plugin in unloaded when Cinema 4D ends. See Plugin Functions Manual.
Classic plugins are created by implementing a plugin class e.g. ObjectData or TagData. Such an implementation must be registered in PluginStart() using a specific function like RegisterObjectPlugin(). See General Plugin Information Manual.
C4DAtom is the base class for many elements of the classic API. It gives access to the element's type, its parameter Description, parameter values and dirty state. The class is also used to copy the element and send messages to it. See C4DAtom Manual.
GeListNode is another frequently used base class. It allows to organize elements in lists and trees. It also gives access to the element's document and registration information. See GeListNode Manual.
The base class BaseList2D provides functions to handle the element's name, animation tracks, internal data, bits, shaders, layers and IDs. See BaseList2D Manual.
The functions C4DAtom::GetParameter() and C4DAtom::SetParameter() allow to access the parameter values of objects, materials, tags etc. The ID of such a parameter is defined using a DescID object. Such a DescID object is composed of multiple DescLevel elements. The complete DescID is also needed when handling an animation track of a given parameter. See DescID Manual.
An interface is a public abstract declaration of a class. Such an interface can be implemented one or multiple times; such implementations are separated from the public interface declaration. This interface system is the base for most MAXON API ALIASES classes. See MAXON API Interfaces.
The MAXON API ALIASES makes heavy use of reference counting. New instances of a given class are typically handled as reference counted objects. The instance will be freed when all references using that object are deleted. See References.
A registry is used to store implementations of a given interface. Using such a registry it is possible to access all implementations of that interface. See Registries.
A published object gives access to a certain object. This can be any kind of object in memory; typically it is a class representing an implementation of an interface. See Published Objects.