Re: SCPreferencesSynchronize not doing its job
Re: SCPreferencesSynchronize not doing its job
- Subject: Re: SCPreferencesSynchronize not doing its job
- From: Allan Nathanson <email@hidden>
- Date: Wed, 13 Dec 2006 22:03:09 -0500
How does your code pick up the changes? Specifically, does your
application use the SCPreferences APIs to access the changed data? or
are you looking for the changes with an alternate set of APIs?
Does your application make any blocking calls which might delay when
you pick up the SCPreference notification?
Can you expand on your current solution where you "simply poll for the
key"? How are you polling? with SCPreferences API calls?
- Alan
On Dec 13, 2006, at 7:19 AM, email@hidden wrote:
I have a tool which adds a network service via System Configuration
data store manipulation. It needs root access, so it is called from
a parent application through AuthorizationExecuteWithPrivileges().
The tool runs successfully, and if System Preferences is up and
running, it picks up the change immediately. My application which
was responsible for actually running that tool however, will not see
the new data for up to five seconds after the commit and apply.
What's worse, this condition isn't 100% reproducible and only
happens occasionally. Whether or not it works seems to be somehow
related to the amount of time that elapses between the presentation
of the authentication dialog and the time that the tool actually
runs. If I authenticate immediately, it's fine. If I poke around in
the debugger for a minute or two, it flounders.
It does not matter if I call SCPrefsSynchronize or open an entirely
new connection to the database, my code simply will not pick up
these changes for some time after they have been made.
I attempted to make use of SCPreferencesSetCallback and
SCPreferencesScheduleWithRunLoop, and while these calls were
successful, my callback is never hit.
My solution for now is to simply poll for the key I'm looking for
after the tool runs for up to 5 seconds, but this is unbelievably
ugly looking and I don't think it should be necessary.
Any clues as to what's going on here? The call chain is basically:
Cocoa app -> child thread -> AEWP -> Foundation Tool -> SCPrefs
commit/apply
Again, System Preferences picks this up immediately without issue.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden