Adobe 65007312 Programming Guide - Page 97

Creating observable property tables, Adding observers to tables

Page 97 highlights

CHAPTER 5: Creating a User Interface for Your Plug-in Binding UI values to data values 97 X Set a Boolean property when a set of Boolean keys are either all true, or when any one is true (LrBinding.andAllKeys, orAllKeys); for more information on how this works, see "Binding multiple keys" on page 105. For details of the LrBinding functions, see the Lightroom SDK API Reference. Creating observable property tables The Lightroom SDK defines a notification mechanism based on observable tables. When a value changes in an observable table (such as the export-settings table), all registered observers (typically LrView objects) are notified. A plug-in uses this mechanism to make UI controls in the plug-in's user interface respond to changes in data properties. The LrView objects that define your UI elements in an Export dialog section are automatically registered as observers of the export-settings table that is passed on creation; see "Adding custom sections to the Plug-in Manager" on page 32. To use export settings in another context, or to define additional program data, use the function LrBindings.makePropertyTable() to create an observable table, and populate it with your own plug-in settings or any other program data. An observable table must be created with a function context, so that Lightroom can clean up the notifications if anything goes wrong. (See "Using function contexts for error handling" on page 18.) A function context is created using LrFunctionContext.callWithContext(). This passes a function-context object to its main function; you pass that object on to your table-creation function. For example: LrFunctionContext.callWithContext("showCustomDialog", function( context ) local properties = LrBinding.makePropertyTable( context ) properties.url = "http://www.adobe.com" -- create a settings value -- add code to take create dialog contents end) When you create a new table, it is initially empty. You can explicitly add keys and values, as in the example. However, it is not necessary to add a key to a table before you reference it in a binding; if it is not yet in the table, its value is nil. The example in "Transforming values" on page 103 shows how a control's value is bound to a key that is not yet in the table. When the control first gets a value, the key is put into the table with that value. TIP: You can use a naming convention to distinguish program data from persistent export settings (that is, those specified in the exportPresetFields table; see "Remembering user choices" on page 57). For example, you might use an underscore prefix, "_tempUrl," to indicate a local data property. Adding observers to tables You can create a general and flexible response to a change in an observable table by adding an observer. An observer associates a function that you define with a key in the table, so that whenever the key value changes, the function is called. To receive notification of changes in the table you create, use this function to register an observer of the table: propertyTable:addObserver( key, func )

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
  • 187
  • 188
  • 189
  • 190
  • 191
  • 192
  • 193
  • 194
  • 195
  • 196
  • 197
  • 198
  • 199
  • 200
  • 201
  • 202
  • 203
  • 204

C
HAPTER
5: Creating a User Interface for Your Plug-in
Binding UI values to data values
97
X
Set a Boolean property when a set of Boolean keys are either all true, or when any one is true
(
LrBinding.andAllKeys
,
orAllKeys
); for more information on how this works, see
“Binding multiple
keys” on page 105
.
For details of the
LrBinding
functions, see the
Lightroom SDK API Reference
.
Creating observable property tables
The Lightroom SDK defines a notification mechanism based on
observable tables
. When a value changes in
an observable table (such as the export-settings table), all registered observers (typically
LrView
objects)
are notified. A plug-in uses this mechanism to make UI controls in the plug-in’s user interface respond to
changes in data properties.
The
LrView
objects that define your UI elements in an Export dialog section are automatically registered
as observers of the export-settings table that is passed on creation; see
“Adding custom sections to the
Plug-in Manager” on page 32
.
To use export settings in another context, or to define additional program data, use the function
LrBindings.makePropertyTable()
to create an observable table, and populate it with your own plug-in
settings or any other program data.
An observable table must be created with a
function context
, so that Lightroom can clean up the
notifications if anything goes wrong. (See
“Using function contexts for error handling” on page 18
.) A
function context is created using
LrFunctionContext.callWithContext()
. This passes a
function-context object to its main function; you pass that object on to your table-creation function. For
example:
LrFunctionContext.callWithContext("showCustomDialog", function( context )
local properties = LrBinding.makePropertyTable( context )
properties.url = "http://www.adobe.com" -- create a settings value
-- add code to take create dialog contents
end)
When you create a new table, it is initially empty. You can explicitly add keys and values, as in the example.
However, it is not necessary to add a key to a table before you reference it in a binding; if it is not yet in the
table, its value is nil. The example in
“Transforming values” on page 103
shows how a control’s
value
is
bound to a key that is not yet in the table. When the control first gets a value, the key is put into the table
with that value.
T
IP
:
You can use a naming convention to distinguish program data from persistent export settings (that is,
those specified in the
exportPresetFields
table; see
“Remembering user choices” on page 57
). For
example, you might use an underscore prefix, “
_tempUrl,
” to indicate a local data property.
Adding observers to tables
You can create a general and flexible response to a change in an observable table by adding an
observer
.
An observer associates a function that you define with a key in the table, so that whenever the key value
changes, the function is called.
To receive notification of changes in the table you create, use this function to register an observer of the
table:
propertyTable
:addObserver(
key
,
func
)