Re: Bindings don't populate dialog fields?
Re: Bindings don't populate dialog fields?
- Subject: Re: Bindings don't populate dialog fields?
- From: Guy Umbright <email@hidden>
- Date: Tue, 17 Jan 2006 22:20:04 -0600
Well I have figured out why they fields did not populate originally,
but I am still left with a problem.
As a sanity check, I did a quick hack of a window editing an object
via bindings project and the
window fields populated as expected. So I looked at where the edited
objects accessors are
first being referenced. What surprised me a bit was that those
initial values are being reference
during the load of the nib. At that is a bit problematic.
I normally place each window in its own nib file and subclass the
controllers off a "nib loader"
class, the core of which is the init method:
//------------------------------------------------------------------
//
//------------------------------------------------------------------
- (id) init
{
self = [super init];
if (self)
{
[NSBundle loadNibFile:[[NSBundle mainBundle]
pathForResource: NSStringFromClass([self
class])
ofType:@"nib"]
externalNameTable:[NSDictionary
dictionaryWithObjectsAndKeys:self,@"NSOwner",nil]
withZone:[self zone]];
}
return self;
}
and here is the init for the window controller (the bindings are to
the 'job' object):
- (id) initWithJob: (Job*) j
{
self = [super init];
if (self != nil)
{
job = [j retain];
}
return self;
}
See the problem? The [super init] causes the bindings to attempt to
access the as of yet uninitialized
job object, and therefore the fields are not populated. When I move the
j=[j retain]
(improperly) to before the
[super init]
everything works.
This leaves me with the quandry of how to deal with this. I don't
HAVE to have the nib load code as
a superclass I suppose, but it made things convenient, simple, and
transparent.
Guy
On Jan 16, 2006, at 9:15 PM, Jeff LaMarche wrote:
On Jan 16, 2006, at 9:56 PM, Guy Umbright wrote:
I have a dialog that uses bindings (via NSObjectController) to
edit an object. If I edit the fields, the new values
show up in the object (with a caveat I will mention later). The
one thing it does not do is populate the dialog
fields with the values in the object when the dialog is displayed.
Dialog or sheet? In my experience, bindings work correctly in both
directions, so if the thing they are bound to has a value, the
value should show up in the fields when the sheet or dialog is
shown. I address the one exception to that below.
I haven't used modal dialogs much under OS X, though, since sheets
are what the HIG says to use in most situations, but I would assume
they would have similar behavior.
Am I missing something or should those initial values from the
object be displayed in the dialog?
You might need to give more specifics. From your description, it
does sound like it should be working, but it's a little vague to
really diagnose a problem.
Also, the text fields in the object only update if I leave the
field after editing. Usually you don't leave
the field after editing and just hit the OK. Is there a standard
way to force this final update?
For this situation, what you probably need to do is send the dialog
or sheet a makeFirstResponder:nil message when the sheet or dialog
is dismissed. I've found that while a field is the first responder,
it will not take updates made programmatically to the entity or
object it is bound to. I assume that this behavior is because the
system assumes that the user is interacting with the first
responder, and therefore gives preference to the value entered by
the user over the one done programmatically... but that's just a
guess. It does seem like a control on a sheet or dialog should
yield first responder status after being dismissed, but like I
said, I've found some instances where it doesn't - where a field on
the sheet maintains first responder status for a short time after
it is dismissed. If the KVO notification happens while the field
still retains first responder status... the update doesn't happen.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden