Initial Prefs Setting Of Checkbox?
-
i have a few checkboxes in my prefs window which are bound... however,
i was under the impression that i could easily set the very first load
state of these boxes in IB by checking "Selected" (Inspector >
Attributes > Visual > Selected) before the userdefaults are written...
it doesn't seem to work... should this work or am i just dreaming? do
i really have to write code for this? and if so, what's the use of
being able to check Selected in IB? -
On 31 Dec 2008, at 3:25 pm, Chunk 1978 wrote:
> i have a few checkboxes in my prefs window which are bound... however,
> i was under the impression that i could easily set the very first load
> state of these boxes in IB by checking "Selected" (Inspector >
> Attributes > Visual > Selected) before the userdefaults are written...
> it doesn't seem to work... should this work or am i just dreaming? do
> i really have to write code for this? and if so, what's the use of
> being able to check Selected in IB?
First off, I'll declare my lack if in-depth knowledge about bindings.
But seems to me you wouldn't expect this to work. A UI widget is only
representing a state in your data model, it is not the model (or
shouldn't be). So trying to set some initial state in your model by
checking the UI in IB is backwards. Instead your code should be
initialising the state of the model to a desired state, then the UI
will follow (automatically, if its bound).
With preferences (user defaults) there is an API for registering the
desired initial first state: -registerDefaults:
The use of setting the state in IB is, I guess, that sometimes you
will know that a given state defaults to YES. But to be honest I would
never rely on it - you should always set a UI to match the data model
state it is viewing. With KVO (and by extension, bindings) this is
taken care of pretty much for you.
You don't need to write any code to deal with this, except one line at
app start-up that reads your default state from a plist and calls -
registerDefaults: with it. If your app needs to set certain defaults
in order to work you'll have to do that anyway.
--Graham -
On Tue, 30 Dec 2008 23:25:03 -0500, "Chunk 1978" <chunk1978...> said:
> i have a few checkboxes in my prefs window which are bound... however,
> i was under the impression that i could easily set the very first load
> state of these boxes in IB by checking "Selected" (Inspector >
> Attributes > Visual > Selected) before the userdefaults are written...
There are two misunderstandings here, and the most important of them is the
second one, "before the user defaults are written". There should be NO SUCH
TIME. It is up to you register the default defaults (that is, the "initial"
value for user defaults before the user has had any chance to express an
opinion) before the app even finishes loading for the first time. That is
exactly what "registerDefaults" is for. In some cases, finding a
sufficiently early entry point can be a challenge; I typically resort to
+initialize.
m.
--
matt neuburg, phd = <matt...>, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
One of the 2007 MacTech Top 25: <http://tinyurl.com/2rh4pf>
AppleScript: the Definitive Guide - Second Edition!
<http://www.amazon.com/gp/product/0596102119> -
ok i get that... however, what if a developer intends to leave all
checkboxes in preferences unchecked as the initial defaults, and there
are only checkboxes or radio buttons, no colors, no numbers, etc... is
it considered bad practice to not register these defaults if they are
bound? or is it better to keep code to a minimum and not register the
defaults... are there any problems that can arise from not having
defaults registered if their initial settings of the checkboxes is
desired?
On Wed, Dec 31, 2008 at 12:34 PM, Matt Neuburg <matt...> wrote:
> On Tue, 30 Dec 2008 23:25:03 -0500, "Chunk 1978" <chunk1978...> said:
>> i have a few checkboxes in my prefs window which are bound... however,
>> i was under the impression that i could easily set the very first load
>> state of these boxes in IB by checking "Selected" (Inspector >
>> Attributes > Visual > Selected) before the userdefaults are written...
>
> There are two misunderstandings here, and the most important of them is the
> second one, "before the user defaults are written". There should be NO SUCH
> TIME. It is up to you register the default defaults (that is, the "initial"
> value for user defaults before the user has had any chance to express an
> opinion) before the app even finishes loading for the first time. That is
> exactly what "registerDefaults" is for. In some cases, finding a
> sufficiently early entry point can be a challenge; I typically resort to
> +initialize.
>
> m.
>
> --
> matt neuburg, phd = <matt...>, <http://www.tidbits.com/matt/>
> A fool + a tool + an autorelease pool = cool!
> One of the 2007 MacTech Top 25: <http://tinyurl.com/2rh4pf>
> AppleScript: the Definitive Guide - Second Edition!
> <http://www.amazon.com/gp/product/0596102119>
>
>
>
>
-
On Wed, 31 Dec 2008 14:59:13 -0500, "Chunk 1978" <chunk1978...> said:
> ok i get that... however, what if a developer intends to leave all
> checkboxes in preferences unchecked as the initial defaults, and there
> are only checkboxes or radio buttons, no colors, no numbers, etc... is
> it considered bad practice to not register these defaults if they are
> bound? or is it better to keep code to a minimum and not register the
> defaults... are there any problems that can arise from not having
> defaults registered if their initial settings of the checkboxes is
> desired?
Yes - the problems that you were experiencing that you described in your
original post. m.
--
matt neuburg, phd = <matt...>, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
One of the 2007 MacTech Top 25: <http://tinyurl.com/2rh4pf>
AppleScript: the Definitive Guide - Second Edition!
<http://www.amazon.com/gp/product/0596102119> -
On 1 Jan 2009, at 6:59 am, Chunk 1978 wrote:
> ok i get that... however, what if a developer intends to leave all
> checkboxes in preferences unchecked as the initial defaults, and there
> are only checkboxes or radio buttons, no colors, no numbers, etc... is
> it considered bad practice to not register these defaults if they are
> bound? or is it better to keep code to a minimum and not register the
> defaults... are there any problems that can arise from not having
> defaults registered if their initial settings of the checkboxes is
> desired?
Basically if your defaults are 0, NO or NULL/nil for any setting, you
can safely just not bother with registering them. That's because these
are the values returned for a missing key.
You only need to register the defaults that have to be set to a value
other than these. I typically design my defaults so that an absence of
a value is the default default (aside: why "preferences" got changed
to "defaults" is a mystery - it leads to confusion when discussing the
defaults for preferences). For things like colours, you can substitute
the default colour at runtime if you get a nil value back from the
default - that is another way to avoid the need to use
registerDefaults, but often it's useful to just use a plist with
registerDefaults: so you can quickly edit the settings without
hardwiring them into your code.
--Graham
