Window Keyboard Event Binding

[RyanBurnside]

Hello,

One thing that I'm wanting to do is bind some keyboard events to my game in the same way the mouse bindiings are done.

Essentially, I've got keys like A S D F J K that I'd like to be able to write a callback on key press.

Binding mouse event in a window is as easy was writing a function that accepts a window and does whatever (firing twice - once on mouse down and again mouse release).
I was hoping to be able to do the same with keyboard keys where they just get silently responded to in the window.

Bonus question:
Is there a way in Medley to use lexical scope closures cleanly for callback functions?
For example, I'd like my callback function to close over some external data (like a Common Lisp closure) and do something on it without having to store that data directly. This lets me store data without having to tuck it into the window properties.

Thanks for your help!

[RyanBurnside]

I suppose the "Bonus" question has been answered by Medley itself.

I made a test counting closure using FUNCTION/LAMBDA and was advised to use Common Lisp closures instead.
Fair enough. I guess my main question now is that button callback on a window'd project.

[RyanBurnside]

Excellent! Thank you Matt! (This'll work!)

Well, I've not been quite sure how to Create a Common Lisp function directly.
Do I need to call ED(my-cl-function) from a Common Lisp executive?

That would be an acceptable solution, write the closure building function in CL, then bind the result to the Window's click event. It'd return a CL closure function which could be bound: (MY.CLOSURE (WINDOW) ... state stuff ...)

[RyanBurnside]

Ah, but now I realise that I can't quote the Interlisp LET* further up...
Not a deal breaker, I have other strategies for storing things.

[pamoroso]

You can create a Common Lisp function also from an Interlisp Exec like this:

ED(my-cl-function FUNCTIONS :DONTWAIT)

Be sure to provide any suitable package qualifiers in the function name.

[MattHeffron]

Ah, but now I realise that I can't quote the Interlisp LET* further up...

I think, instead of the explicit CL:EVAL of the quoted LET*, I'd just have a CL:DEFUN function that creates the closure. Something like:

(DEFUN yourPackage::MAKE-CALLBACK (W WBM BSTRM CIRCS)
  #'(CL:LAMBDA (WINDOW)
      (SHIFT.BALL.COLORS (CAR CIRCS))
      (DRAW.RINGS CIRCS BSTRM)
      (BITBLT WBM 0 0 W)))

Then setting the WINDOWPROP would be:

(WINDOWPROP W 'BUTTONEVENTFN
      (yourPackage::MAKE-CALLBACK W WIN.BITMAP BUFFER.STREAM CIRCS.LIST)

Calling MAKE-CALLBACK creates the lexical closure based on the argument names, binding the values from the parameters passed.
I believe that the WINDOW parameter passed to the callback is the window that the BUTTONEVENTFN is attached to. In that case, the MAKE-CALLBACK doesn't need the W argument, as it would be the same as what's passed to the closure through the WINDOW argument. Then like:

(DEFUN yourPackage::MAKE-CALLBACK (WBM BSTRM CIRCS)
  #'(CL:LAMBDA (WINDOW)
      (SHIFT.BALL.COLORS (CAR CIRCS))
      (DRAW.RINGS CIRCS BSTRM)
      (BITBLT WBM 0 0 WINDOW)))

And setting the WINDOWPROP would be:

(WINDOWPROP W 'BUTTONEVENTFN
      (yourPackage::MAKE-CALLBACK WIN.BITMAP BUFFER.STREAM CIRCS.LIST)

NOTE: I didn't try any of this. It's all just thinking -> posting.

Edit: remove incorrect parens.

[RyanBurnside]

@MattHeffron The Common Lisp function approach works well it seems - thanks. I might use closures from now on when working with windows to avoid creating a bunch of slots. It didn't make the Game Jam but this will probably be my go to approach for storing state and not polluting windows too much when sensible. Although it does make inspection a bit more annoying. All well, choices ... choices. But having choice is why I use Lisp in general.

In this example I form a closure around a list without storing it in the Window. I then iterate and print it to a window's display stream. I guess the fn name should have changed after my hacking (more of a CONSer now.)

[nbriggs]

I think there are a couple of ways to deal with the button callback - you could run a loop (including a call to (BLOCK), so things don't lock up) that tests for when (KEYDOWNP 'keyname) happens, whenever the mouse/cursor is in the game window. Alternatively, I think you could make the keys interrupt characters using (INTERRUPTCHAR ...) [see the IRM for the documentation], and arm/disarm those when the mouse/cursor is in the game window.

…

-- Nick

On Nov 7, 2025, at 18:49, Ryan Burnside ***@***.***> wrote: I suppose the "Bonus" question has been answered by Medley itself. Screenshot_20251107_194637.png (view on web) <https://github.com/user-attachments/assets/6206b076-f882-4f0e-8a0b-cccc53ac04ef> I made a counting closure using FUNCTION/LAMNDA and was advised to use Common Lisp closures instead. Fair enough. I guess my main question now is that button callback on a window'd project. — Reply to this email directly, view it on GitHub <#2359 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6DAWJA4SLQQE76QC6ZCXD33VK4DAVCNFSM6AAAAACLPTA7PCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIOJQHAZTMNI>. You are receiving this because you are subscribed to this thread.

[RyanBurnside]

Nick, as always thanks!
Seems fairly low level stuff, we'll see if I can figure it out before the end of the Game Jam. :)

[masinter]

Interlisp EVAL and Interlisp compiled code don't create lexical contexts.

So (LET ((FOO 42)) (....))

doesn't create a lexical scope so there is nothing to close over.

If you wrap it in a CL:LAMBDA though you'll get lexical bindings
(CL:FUNCALL #'(CL:LAMBDA (&AUX (FOO 42)) (CL:INCF FOO))))

will return a lexical closure with the value of FOO captured (I changed it to INCF just to illustrate)

[RyanBurnside]

Thanks Larry!
I understand the example, a rare example of &AUX in the wild. :)
So I guess my follow up question is:
Does Common Lisp have it's own CL:LET by chance which creates lexical scopes callable from the IL environment?

[RyanBurnside]

I was able to create the lexical LET from forcing LAMBDA to establish lexical scope then returning a closure from inside with the captured lexical scope. (I know Interlisp features generators that do this but this was just a test for me to avoid polluting the toplevel and Window fields.)

Thanks Larry!

[nbriggs]

WINDOWPROP just stores whatever additional properties you create as a property list on the USERDATA field in the WINDOW datatype. That doesn't "pollute" window fields, and it does make it easy to use the inspector to see what's going on vs. the state in a closure -- especially if it's compiled:

[masinter]

the Medley debug tools don't know much about closures. TBH I've never quite understood the enthusiasm for lexical scoping in Lisp. The implementation of lexical scoping winds up making closure objects so there is no advantage, and conceptually you're better off with just using RECORD (or TYPERECORD when debugging/developing) and storing the runtime game state as CONS cells.