« On Urinals and Bars | Main | more on being in charge »

When last we left our intrepid hero, he had gotten his application, sans plotting, into a basically functional state. Then he went to Shane Stanley's awesome AppleScriptObjC class, and learned about bindings.

Things got interesting.

So, leaving the hyperbole behind, Bindings are a different way to well, bind UI controls to the code in your application. They can make your life much easier, in that you can get the same task done with less work and, quite often, less code. But, they do require you to think about things differently. So, we'll cover bindings in multiple passes, with this article talking about text fields. Text fields are a good start because the WiFi Analyzer has a fair amount of them, and they're pretty simple to deal with, once you know a couple things.

So, as you recall, the non-bindings way we use text fields is pretty simple. We set up the field name in the application as a property with a value of "missing value":

property currentSSID : missing value

Then in Interface Builder, we create the text field, and do the ctrl-drag thing to connect the text field to the property. We can then use it in the application like so:

currentSSID's setStringValue_(theCurrentInterface's ssid())

This sets value of the text field's string value to the value of theCurrentInterFace's SSID. To get the contents of that string value:

currentSSID as text

Simple enough. So how do we do this with bindings? Well, the difference in the setup is minor. First, you set your property up to be an empty string, not missing value:

property currentSSID : ""

Then, in Interface Builder, you select the text field, and open up the Inspector. In that, you enable bindings, and pick your application delegate, (in this case, Wi Fi Analyzer App Delegate), and in the Model Key Path, you enter the property you're binding the control to. I highly recommend pasting this in, it avoids really annoying problems:

Save this change, and sweet, we're done, right? No dragging, no other changes!

Welllllll...no. That's what I initially thought, and nothing seemed to work. The text field wasn't set, writing the value failed all over the place, it was a mess. The reason why, once some folks on the core AppleScript team explained it is simple. When you use the non-bindings method, then you're working with a pointer to the data. So, things like setStringValue_() work and you have to specify "as text" when you're using it. With bindings, you're working with the actual data itself, not a pointer to the data, so you have to use more 'traditional' AppleScript methods:

set my currentSSID to theCurrentInterface's ssid()

and

currentSSID

Once you realize this it's pretty simple. Also, I realize that there's not a huge difference in code or convenience between bindings and non-bindings for text fields, at least not in the way we're using them. However, as we'll see in the next iteration of this, when we move to other controls, bindings can simplify our lives rather a lot.

Comments

When last we left our intrepid hero, he had gotten his application, sans plotting, into a basically functional state. Then he went to Shane Stanley's awesome AppleScriptObjC class, and learned about bindings.\n\nThings got interesting.\n\nSo, leaving the hyperbole behind, Bindings are a different way to well, bind UI controls to the code in your application. They can make your life much easier, in that you can get the same task done with less work and, quite often, less code. But, they do require you to think about things differently. So, we'll cover bindings in multiple passes, with this article talking about text fields. Text fields are a good start because the WiFi Analyzer has a fair amount of them, and they're pretty simple to deal with, once you know a couple things.\n\nSo, as you recall, the non-bindings way we use text fields is pretty simple. We set up the field name in the application as a property with a value of \"missing value\":\n\nproperty currentSSID : missing value\n\nThen in Interface Builder, we create the text field, and do the ctrl-drag thing to connect the text field to the property. We can then use it in the application like so:\n\ncurrentSSID's setStringValue_(theCurrentInterface's ssid()) \n\nThis sets value of the text field's string value to the value of theCurrentInterFace's SSID. To get the contents of that string value:\n\ncurrentSSID as text\n\nSimple enough. So how do we do this with bindings? Well, the difference in the setup is minor. First, you set your property up to be an empty string, not missing value:\n\nproperty currentSSID : \"\"\n\nThen, in Interface Builder, you select the text field, and open up the Inspector. In that, you enable bindings, and pick your application delegate, (in this case, Wi Fi Analyzer App Delegate), and in the Model Key Path, you enter the property you're binding the control to. I highly recommend pasting this in, it avoids really annoying problems:\n\n\n\nSave this change, and sweet, we're done, right? No dragging, no other changes!\n\nWelllllll...no. That's what I initially thought, and nothing seemed to work. The text field wasn't set, writing the value failed all over the place, it was a mess. The reason why, once some folks on the core AppleScript team explained it is simple. When you use the non-bindings method, then you're working with a pointer to the data. So, things like setStringValue_() work and you have to specify \"as text\" when you're using it. With bindings, you're working with the actual data itself, not a pointer to the data, so you have to use more 'traditional' AppleScript methods:\n\nset my currentSSID to theCurrentInterface's ssid()\n\nand\n\ncurrentSSID\n\nOnce you realize this it's pretty simple. Also, I realize that there's not a huge difference in code or convenience between bindings and non-bindings for text fields, at least not in the way we're using them. However, as we'll see in the next iteration of this, when we move to other controls, bindings can simplify our lives rather a lot.