XCMDGlue attempts to handle as many of these callbacks as it sensibly can, but in many cases it is not possible to define a sensible response, especially for callbacks that refer specifically to entities in HyperCard that do not correspond directly to anything in Director.
If the XCMD you use makes callbacks that Director cannot properly handle, it will usually not work properly. It is, however, possible to write a Lingo factory that will handle unsupported callbacks. (Note the use of the old factory structures here rather than parent scripts; this is one of the occasions when the newer OOP structures do not work). A callback factory may allow the XCMD to be used as desired, but this is by no means guaranteed.
The process of defining a callback factory is described (but not *explained*) in Appendix A of "Using Lingo" (an almost exact replica of the equivalent chapter in the Director 3.1 manuals), and I don't propose to reproduce that information here. What I will *attempt* to do is to explain what is actually going on there, but I must admit this is mostly supposition and should be taken with several large ladle-fulls of salt.
XCMDGlue's mDescribe copyright notice dates it 1989-90, at which time Director would probably have been at version 2.0 and HyperCard at 1.x. At that time (it seems) HyperCard provided only 29 callback functions, and XCMDGlue deals with all of these explicitly. 20 of them are just handled automatically. The remaining 9 callback functions cause XCMDGlue to throw up an alert, *unless* it has had a callback factory object attached via the setCallBack method. In that case, XCMDGlue sends a specific message corresponding to each of the 9 unsupported callbacks. It therefore expects a callback factory to have the following methods:
method mEvalExpr expr
method mSendHCMessage msg
method mSendCardMessage msg
method mGetFieldByName card, name
method mGetFieldByNum card, num
method mGetFieldByID card, id
method mSetFieldByName card, name, value
method mSetFieldByNum card, num, value
method mSetFieldByID card, id, value
(Notice that the documentation still refers to there being only 9 unsupported
callbacks even though at last count there were 55.)
Since it was inevitable that more callbacks would be added, XCMDGlue was given an escape route: unknown callbacks would cause a message to be sent to a generic method in the callback factory,
method mUnknown callbackNumwhich would receive the ID number of the unknown callback, but apparently not any arguments it might have (I haven't tested this: it may be possible to receive the arguments for unknown callbacks, though Director 3.1 had no param() function and the method would therefore have had difficulty receiving a variable number of arguments.)
Since then, HyperCard has gained a whole bunch of additional callback functions, but XCMDGlue hasn't changed, so most of the new, unsupported callbacks feed straight into mUnknown. In order that this not be totally unhelpful, the callback factory from the manuals uses the built-in array feature of factories to store the names of all the additional callbacks, and the mUnknown handler looks up the name corresponding to the given number. However, this is only a courtesy.
To define a callback factory of your own, all that is necessary is that you provide methods for any messages that XCMDGlue passes. A factory that has all 10 of the above methods will certainly do, but in many cases only one or two will be needed. mUnknown is particularly likely, since it encompasses more than 40 callbacks that the XCMD might want. However, many of these are very HyperCard-specific, and an XCMD that depends on them may well not be much use for a Director movie.
Note that correctly handling the callback (and possible returning a value) so as to allow the XCMD to proceed correctly will require a more detailed knowledge of what the particular callback does (described in Appendix A of the HyperCard "Script Language Guide" manual), and even then may be impossible -- it's difficult to see how ZeroTermHandle, for example, would be handled in Lingo.