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 ...

Problem

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:

onOptionsChanged
    <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?

Solution

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.