There are three callback models for associating Python callback logic with UIL-defined widgets. The Examples section below demonstrates all of the models. The models are:
With this approach, Python initialization logic attaches widget callbacks to Python functions (and the UIL callback feature is not used). This is likely to be the most popular callback model; if you cannot know which model to use, then use this approach. Example code:
... main = hier.FetchWidget("main", top); main.NameToWidget("*button").AddCallback( 'activateCallback', pythonFunction, "context"); ...
PyRegister registers a Python function using MrmRegister
so that the function will be called as specified in UIL callback
statements. (This model imitates the manner in which UIL specifies
callbacks to C functions and the C program registers the callbacks
during initialization.) One use for this approach would be to
prototype an application in Python and then convert to C code, keeping
the same UIL.
mrm_hier = Mrm.OpenHierarchy(["reg.uid"]) mrm_hier.PyRegister(MyPrint, "widget");
MyPrint, now a Mrm-registered Python routine, can be called
directly from UIL.
PyEval is a UIL-callable function (automatically-registered)
that dynamically interprets its string argument as Python code. This
approach allows the logic associated with each callback to be entirely
specified in the UIL module. This approach is somewhat experimental.
PyEval function is described above. Example UIL code:
procedure PyEval(string); ... XmNactivateCallback = procedure PyEval("MyPrint(g_var)");
The string "MyPrint(g_var)" is evaluated by the Python interpreter
whenever the activate callback is invoked. Evaluating the string is
PyEval caches the compiled Python code object
the first time the string is evaluated and compiled. Subsequently,
the code object can be evaluated without having to be compiled.