[plt-scheme] Extensibility of MrEd

(One month later....)

Matthew Flatt wrote:
> I don't think there's currently a way to extend the messages recognized
> by a frame, but it's something we could add.
>
> Beware that there's a bad interaction between PLT Scheme threads and
> Windows: a Scheme-level thread swap cannot be allowed while handling a
> Windows message. The solution is usually to handle a message by just
> queuing a callback in the eventspace, and then return to Windows
> immediately; that works when you don't need to compute any particular
> return value for the message. Would that strategy work for the messages
> that you need to handle (if you had a way to install a handler)?
>   

That strategy would work.  And I think (handwaving) that for my 
Windows-specific needs it could work entirely without hacking on MrEd.  
The app at startup would subclass each wx-created frame window, 
installing therein its own wndproc that sniffs for the private messages 
and queues an appropriate callback.

(class frame% ()
(define/public (on-init) (register-hocuspocus (get-handle)))
(define/augment (on-close) (unregister-hocuspocus (get-handle)))
(define/public (on-hocuspocus x y dx dy) whatever)
 etc)
;; create previous, then send it on-init

/* mzscheme extension - hocuspocus.c */
Scheme_Object* register_hocuspocus(whatever-thunks-to-a-HWND h)
{ /* save away existing wndproc of h, install sniffer proc in its stead */ }
LRESULT CALLBACK SnifferWndProc(HWND h, UINT msg, WPARAM, LPARAM)
{ /* if msg is one of ours, crack the params and queue a hocuspocus 
callback on h's frame%, else invoke previous proc */ }

The callback needs to end up in the context of the frame% corresponding 
to that particular window, as if it had been dispatched via send in 
Scheme, and should arrive with the same priority as other interactive 
events.  At present it's not obvious to me how to do either of these.

Ben