Skip to main content

Connecting fields

Quick Recipe

To connect field a in obj1 to field b in obj2, use this:
obj2 startScript: #b: when: {obj1. #aChanged}
Now for the whole story ...


A colleague of mine wanted to make a drop-down list, where the options are not just set once, but provided and updated by the application. So, of course, when the options in the application changes, the items of the list widget have to be set to this new value. Nothing easier than that, just write a handler:
    <on: optionsChanged in: app>
    listWidget items: app options
HOWEVER, he wanted to build this programmatically, not using a separate method. So, he easily came up with the following:
listWidget startScript : #items: withArguments: {app options} when: {app. #optionsChanged}
HOWEVER, this does not work as intended because the arguments to the script are evaluated only once, rather than every time the script is triggered. Well, this is what blocks are for, right? So this indeed works as intended:
listWidget startScript: [listWidget items: app options] when: {app. #optionsChanged}
HOWEVER, using blocks as long-lived scripts is discouraged. They're hard to identify in inspectors, hard to debug, etc. Alas, there seems to be no easy way around them. Or is there?


I've seen this problem a few times now, and the solution is so simple that I keep forgetting about it (which is why I spell it out here). This is how to wire the two fields:
listWidget startScript: #items: when: {app. #optionsChanged}
Doh! Where are the arguments? Well, the current value of a field is actually a parameter of the field change event (the previous value is the second one). Most of the time we just ignore it, since it's easy to get at the current value, but nevertheless, it's there. So, when #items: is triggered by the change event, its argument is the current value of the changed field, options. (This, btw, is a difference between #startScript: and #perform:, script arguments are optional, whereas method arguments are mandatory).

Of course, you can use the same technique in a regular method:
onOptionsChanged: newOptions
    <on: optionsChanged in: app>
    listWidget items: newOptions
But the earlier version at the top seems a bit more readable to me.


Anonymous said…
Can you fix the post that has this text:

<on: optionsChanged in: app>

in it unencoded? Your atom feed doesn't parse as a result - see:

for details

Popular posts from this blog

Frontend-only Multi-Player. Unlimited Bandwidth. Or: What is, really?

A multi-player web app needs a backend, right? What if I told you, it doesn’t? Read on for how Croquet gets rid of servers running your multiplayer code. No, really . Instantaneous Shared Experiences  is how we describe Croquet on our website. And while that excellently describes What Croquet does, as Croquet's Chief Architect, I wanted to share a bit about How we do that. So I wrote a Twitter thread . Here it is in blog form, slightly extended. Click the animation above if it does not play automatically Croquet lets you build completely client-side multi-user web apps. Read that again. Client-side. Multi-user. No I’m not kidding. I built it, I know it works. 😁  Croquet apps run completely client-side: are hosted as a static web site no server-side code needed no networking code needed  Croquet is literally virtualizing the server: Instead of running code on a server (or in a serverless function) we run it as a virtual machine (VM) on each client.  Croquet carefully control

Deconstructing Floats: frexp() and ldexp() in JavaScript

While working on my  SqueakJS VM, it became necessary to deconstruct floating point numbers into their mantissa and exponent parts, and assembling them again. Peeking into the C sources of the regular VM, I saw they use the  frexp ()   and ldexp () functions found in the standard C math library. Unfortunately, JavaScript does not provide these two functions. But surely there must have been someone who needed these before me, right? Sure enough, a Google search came up with a few implementations. However, an hour later I was convinced none of them actually are fully equivalent to the C functions. They were imprecise, that is, deconstructing a float using frexp() and reconstructing it with ldexp() did not result in the original value. But that is the basic use case: for all float values, if [ mantissa , exponent ] = frexp (value) then value = ldexp ( mantissa , exponent ) even if the value is subnormal . None of the implementations (even the complex ones) really worked. I

Smalltalk Bindings for Minecraft Pi

The Raspberry Pi is a cute little computer. Quite cheap at $35, you plug in USB keyboard+mouse and a TV as monitor. And it is surprisingly capable, even for running 3D games. One particularly interesting game is Minecraft: Pi Edition . As in other Minecraft versions, the main goal is to create a world. But unlike other versions, you can not only use the tools provided by the game, you can make your own tools! That's because it comes with a programming interface. The Minecaft world is made of little cubes, and you normally place or remove these blocks by hand, one after another. This is fun, but for larger structures also quite cumbersome. For example, this rainbow here might take a long time to construct manually: But I did not make the rainbow by hand. I programmed it, using the Smalltalk programming language. It's just these dozen lines of code in the Squeak programming environment: Squeak is already installed on the Raspberry Pi, because Scratch was made in Squeak