Someone posted a while back that these functions caused no end of difficulties for their application. For myself, I have done okay with them, but they are a real pain.

I occurs to me, that many of the CAPI functions that alter data in panes and interfaces don't actually directly draw on the screen or other pixmaps, but rather call some form of GP:INVALIDATE-xxx to queue up the needed drawing changes. If this were not the case, then it seems to me that DISPLAY-CALLBACK routines would lose their usefulness... (I could be wrong about this...)

It seems that much of the difficulty could be averted simply by incorporating an MP:LOCK among the slots of new pane and interface classes, and that user code and CAPI-process callbacks could more easily get along by adhering to the use of MP:WITH-LOCK surrounding any code that alters the interface or its panes.

I just tried this, and it appears to work just fine... so far...

The difficulties spawned by APPLY-IN-PANE-PROCESS, and EXECUTE-WITH-INTERFACE, appear to have more to do with proper inter-process coordination than anything else. Of course, if a routine actually calls GP drawing functions, then these should occur only in the CAPI process (for LWM Cocoa, in particular). But other kinds of functions such as altering lists of collection items, changing display parameters, etc., seem like they could be safely performed by any process, so long as one adheres to the WITH-LOCK protocol.

This, of course, is the generally accepted and proper form of coding for multiple-process applications. Leaving it to the user to be certain that some functions only occur in one particular process is just asking for trouble. Nicht wahr?

(Sort of reminds me of why I prefer Lisp, and shun C, for the memory management. Handling memory in C feels similar to the contortions we face in using APPLY-IN-PANE-PROCESS and EXECUTE-WITH-INTERFACE.)

Does anyone have any experiences with CAPI that would indicate otherwise?