Window Registry

  • Thread starter Thread starter Sam
  • Start date Start date
S

Sam

Hi all

If I only want to store screen location and size of my application in
Windows Registry, which of the keys should I store this info? A sample code
is greatly appreciated. Thank you

Regards,

Sam
 
Sam said:
If I only want to store screen location and size of my application in
Windows Registry, which of the keys should I store this info?

You can use 'Microsoft.Win32.Registry' to store data in the registry. For
more information, read the documentation of this class. If you have any
further questions on this topic, feel free to post them here.
 
Hi Herfried

Thanks for the response. I think my question wasn't that clear and I'm a
little confused, so let me rephrase it. when I ran regedit on my Window run
command, I saw 5 major groups:

1. HKey_Classes_Root
2. HKey_Current_User
3. HKey_Local_Machine
4. HKey_Users
5. HKey_Current_Config

Now if I use classes Registry and RegistryKey to access and store my
application specific, which of the above should I store my application's
size and location? Is there a convention for this? I'm new to this

Regards,

Sam
 
Sam said:
Thanks for the response. I think my question wasn't that clear and I'm a
little confused, so let me rephrase it. when I ran regedit on my Window
run
command, I saw 5 major groups:

1. HKey_Classes_Root
2. HKey_Current_User
3. HKey_Local_Machine
4. HKey_Users
5. HKey_Current_Config

Now if I use classes Registry and RegistryKey to access and store my
application specific, which of the above should I store my application's
size and location?

'CurrentUser'. Take a look at the documentation of the 'Registry' class'
members. You will find information on which data to store in which of these
registry branches there.
 
Storing configuration parameters in Registry is not recommended anymore.
Your should use a XML file instead. But, for reference:

Each registry hive plays different roles. CurrentUser is used to store
personal information about the user currently logged in the system. Each
user has a CurrentUser. A user has full access to its CurrentUser. No user
can access the CurrentUser of another user. LocalMachine is global to any
user logged in, but only members with administrative priviledges can write
to it. Other users, non administrators, can only read the keys stored in
LocalMachine. Usually, you shold pick one of this too, depending on the kind
of information your are storing and the level of access required. As it
seems, if yours configuration is read-only to non administrators users, the
best location for your configuration is LocalMachine. But remember: ordinary
users running your application will not be able to change any key or value.
If this is required, use CurrentUser. This only apply to Windows NT, Windows
2000, Windows XP and Windows 2003. In Windows 9x e Me, any user has full
access to all registry keys, including LocalMachine.
 
1) Is the machine on which this app is running shared by multiple users?
If it is not, use HKey_Current_User.

2) If it is, do you want the settings to apply to all users who share the
machine?
If you do, use HKey_Local_Machine.
If you want each of the users who share the machine to be able to have
individual settings, use HKey_Current_User.
 
Hi Mark

Thanks for the explanation. Ideally I'd like to have the application running
on the machine shared by multiple people and each should have their own
settings. What I'm not sure is how complicated this could be since this is
new to me. I guess if I choose to implement this way, I need to create
something like
HKey_Current_User\Software\MyApplication\UserID1\MyAppLocation?

If the above is too complicated, I might just go down the path that apply
the settings to all users.

Regards,

Sam
 
First of all, there are rumors that Registry will not exist as we know
today. It will be replaced by some kind of structure in XML. And, as a
experienced support guy, i never liked the way people store information in
Registry. This always result in some kind of problem when distributing an
application. As .net assemblies does not require aditional setups, like COM
for example, its a very good practice to put all your app configuration
inside a XML file. Your applications will not need any special priviledge in
secure systems, with policies for example. You just need to copy your
assemblies and support files and your are done. I am now on the side of
programmers and I cant forget the pain of being on the side of support
staff. I think every programmer should spend a few months with the support
staff before start programming.
 
John,

Can you give us a more secure link than *Rumors*. You know that millions of
people in long and short time history are murdered because of rumors.

That somebody does something wrong does not mean that everybody does it
always wrong.
Because that are as well a lot of people innocent killed in history.

I have seen programmers here to ask how to shut down automaticly a system
from VBNet.
I think that nobody should ever give answers to that kind of question.

However using the registry to store by instance the last form settings is a
very legal way of using the registry. It is completly dependend from that
workstation.

Being able to help people to use the registry right is only an advantage.

Just my thought,

Cor
 
John,

John Smith said:
First of all, there are rumors that Registry will not exist as we know
today. It will be replaced by some kind of structure in XML.

Do you really believe that? There are /millions/ of applications currently
using the registry. It's a nice vision that the registry will be replaced
by something else, but it won't disappear. It /cannot/ disappear for
compatibility reasons.
And, as a experienced support guy, i never liked the way people
store information in Registry. This always result in some kind of
problem when distributing an application. As .net assemblies does
not require aditional setups, like COM for example, its a very
good practice to put all your app configuration inside a XML file.

Personally, I don't think this is the best solution. I always hated digging
into config files, INI files and XML files, which are the worst of all in
matters of human readability only to find a value. The registry has search,
import and export capabilities. It shows everything in an
easy-to-understand folder structure and includes editors for the different
types of keys.

I don't want to say that XML files don't make sense at all, but at least as
long as there is no standardized format and no specialized editors included
in Windows, it's a file format that is perfect for an XML processor only,
but not for an admin who has to configure a system or a normal user who
doesn't understand XML at all.
Your applications will not need any special priviledge in secure systems,
with policies for example. You just need to copy your assemblies and
support files and your are done.

Well, as always, there are exceptions.
 
I heard that rumors during a MOC course. There are almost no reference about
accessing registry in the current MOC courses. Every operation linked to
"saving and retrieving app configuration" is implemented with some kind of
XML technique. One of the Instructors said that Registry will change in
future versions of Windows and that it will be build in some kind of XML
structure. Those Instructors usually do trainning with microsoft staff. So,
that rumor may be true. The advantages of having an assembly that has
everything it needs to run is obvious. All instructors keep saying it over
and over: "Just compile, copy and run.". System administrators tends to
close their systems even more due to virus, worms and other security
concerns. Its a good practice avoid using Registry if you can do the same
operations with the new XML features. Use Registry if you really need. But,
like I said, its just a recommended practice (using XML) and the rumor is
just a rumor. Maybe registry never changes or your application will be
obsolete at that time. So, dont worry about that.
 
John,

Exactly, however nobody wrote that an administrator should set the registry
by hand beside you.

The registry is for things that has to be registrated by the program. Not by
the administrator, for that are by instance XML files a good choise, however
those should as well not be accessed direct by an administrator.

When the last of the first happens you can tell in my opinion direct that
the application is probably not well done.

Just my thought,

Cor
 
I believe that this is possible. Windows 3.x configuration was stored in in
INI-like files. Windows 95 introduced a registry much like Windows NT. And,
I can say that, Registry based configuration is bad for system
administrators. My login scripts were plenty of REG lines. Many times i had
to give administrators priviledges to ordinary users because of an
application's need to write do Local Machine. That is bad for security. Some
applications use CurrentUser, but in environments which user profiles are in
use, its a real problem. For each user, you have to load a different setting
when installing or updating. Not all application behave this way, but many
of them do. Its dificult for many programmers, who dont know about Windows
architecture, figure out how to use Registry correctly. In .Net world, this
kind of problem can be eliminated with the simple adoption of an
alternative: XML. Its is as simple as using Registry. Programmers dont have
to think about what kind of security system is in use by the administrator
and, the best part: Administrators only have to copy the assembly, all its
partners to a folder and let the user run the app.

I agree with you when you say about compatibility. I believe that if
Microsoft choose to create a new configuration repository, it will be
compatible with registry for some time, like it was in Windows 3.x to
Windows 9x history. But, its a rumor, only that, like a said. But, anyway,
its better for administrators when they dont have to deal with many registry
configurations for each application.
 
HKey_Current_User\Software\MyApplication\UserID1\MyAppLocation?

Looks OK to me.
If the above is too complicated, I might just go down the path that apply
the settings to all users.

Writing to HKey_Current_User is just as easy as writing to
HKey_Local_Machine...
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Back
Top