Registry wierdness

  • Thread starter Thread starter Hilton
  • Start date Start date
H

Hilton

Hi,

X51, WM 5, using OpenNETCF for Registry changes, viewing registry using IBE
RegEditor

LM\ControlPanel\GPS Settings\hide=1 <-- verified by RegEditor

I run app that removes hide=1 and adds "Group=2". I make sure to both close
and dispose, code is:

try
{
// Open the "GPS Settings" registry key and make it
writable
rk = Registry.LocalMachine.OpenSubKey
(@"ControlPanel\GPS Settings", true);

MessageBox.Show (rk.GetValue ("Hide").ToString ());

rk.DeleteValue ("Hide", false); <-- false means
don't throw exception is value does not exist
rk.DeleteValue ("Redirect", false);
rk.SetValue ("Group", "2",
RegistryValueKind.DWord);
}
catch (Exception ex)
{
MessageBox.Show (ex.ToString());
}
finally
{
if (rk != null)
{
rk.Close ();
rk.Dispose ();
}
}

No exception, I close app. RegEditor reports "hide" is gone and "Group=2" -
correct! GPS Manager does not appear, so I do a warm reboot. After warm
reboot GPS Manager is still not shown and RegEditor shows (the old) "hide=1"
and no Group - wrong!

Why do my registry changes not persist? BTW: "hide=1" is not some default
setting, I created this using RegEditor to simulate some Pocket PCs that get
shipped with that setting.

Wierd...

Hilton
 
Hi,

Seems as though SetValue followed by Close doesn't (immediately) change the
registry; i.e. Close does not Flush, therefore you need to explicitly flush;
now that goes against everything I've ever known about Close for just about
everything I can remember. Anyway, another tidbit of information for y'all
to store away and save you some gray hairs.

I'm almost tempted to recommend to the fine folks at OpenNETCF that they
should add a Flush call in the Close method.

Hilton
 
You would *NOT* want to force that. What if you have 10 keys to change. A
registry write is potentially a 100s of ms process. You wouldn't want your
registry code to incur that cost 10 times over. You'd want to make all of
your changes, something only your application knows about, then call flush
once to do the slow process.

Paul T.
 
Paul,

Agreed. I never said call "Flush" 10 times, I said call Flush once; i.e.
when you Close; e.g.

Open
SetValue
SetValue
SetValue
SetValue
SetValue
SetValue
SetValue
SetValue
Close

*This does not work!!!* You need (at least) one Flush before the Close. My
amazement is that Close does not Flush. I cannot think of any other similar
usage case where Close does not flush; files do, streams do, etc etc. Very
unintuitive, close should flush - period.

Anyway, bottom line, add a Flush before the Close and you're good to go.

Hilton


"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:[email protected]...
 
This is expected and appropriate behavior. I would not expect close to
flush. There are cases where you want to write, but not persist. If Close
always persisted how could you ever achieve that?


--
Chris Tacke - Embedded MVP
OpenNETCF Consulting
Managed Code in the Embedded World
www.opennetcf.com
--



Hilton said:
Paul,

Agreed. I never said call "Flush" 10 times, I said call Flush once; i.e.
when you Close; e.g.

Open
SetValue
SetValue
SetValue
SetValue
SetValue
SetValue
SetValue
SetValue
Close

*This does not work!!!* You need (at least) one Flush before the Close.
My amazement is that Close does not Flush. I cannot think of any other
similar usage case where Close does not flush; files do, streams do, etc
etc. Very unintuitive, close should flush - period.

Anyway, bottom line, add a Flush before the Close and you're good to go.

Hilton


"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:[email protected]...
You would *NOT* want to force that. What if you have 10 keys to change.
A registry write is potentially a 100s of ms process. You wouldn't want
your registry code to incur that cost 10 times over. You'd want to make
all of your changes, something only your application knows about, then
call flush once to do the slow process.

Paul T.
Click to expand...
Click to expand...
 
Back
Top