|
Thanks for the info. I did not know that about GNOME.
John
|
|
|
|
|
The registry is also a single point of failure. 
--
The coolest game in the world: NHL Hockey[^]
|
|
|
|
|
Lounge *coughs* 
I agree partially...I always thought polymorhpic executables would be a better solution still. That way program registry data goes where the program goes. However in defense of Windows registry, I think under some circumstances it's required. You need a standard single location so programs can commumicate if required. I would think that Office suite would be a good example, in that Outlook can probably check the registry for Word's existance and see if spell check is installed if so then enable spell checker for outlook. I don't know if this is how they really accomplish tasks or if they use OLE or something, but it serves as an example of what I mean. If programs stored all data in specialized data files 2 programs that are not related in any way would have a hard time communicating. Atleast it gives you a place to start looking for program INI stuff
Just my opinion
wogerdoger wrote:
If sex is a pain in the ass, then you are doing it all wrong!
Thats great 
I'm drinking triples, seeing double and acting single 
|
|
|
|
|
Hockey wrote:
However in defense of Windows registry, I think under some circumstances it's required. You need a standard single location so programs can commumicate if required. I would think that Office suite would be a good example, in that Outlook can probably check the registry for Word's existance and see if spell check is installed if so then enable spell checker for outlook. I don't know if this is how they really accomplish tasks or if they use OLE or something, but it serves as an example of what I mean.
Good point.
John
|
|
|
|
|
As a programmer I design my software to use both registry and ini files. For the things that the user may need to change or move from pc to pc I put it in ini files. For the small items (less than a KB of data) that the user will never change directly I put in the registry.
John
|
|
|
|
|
I would much rather use the registry because:
all aspects of the computer are stored in one central place.
it is way more hierarchical that INI files; can store more data, and different types of data.
the registry can be secured.
That said, INI files have the same type(s) of arguments. Each are a tool for solving a problem, and like most tools, they can be a benefit, or they can abused and become a hindrance.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Isn't it the purpose of "Application Data" ( or "Local Settings\Application Data" under "Document and Settings" ) the new preferred place to place user settings ?
Also, having only a part of the registry, HKEY_CURRENT_USER, writable should limit the damages.
Maximilien Lincourt
"Never underestimate the bandwidth of a station wagon filled with backup tapes." ("Computer Networks" by Andrew S Tannenbaum )
|
|
|
|
|
wogerdoger wrote:
I can't see why any program settings can't be stored in a file within the directory that the app is installed to
You mean like .INI files? The files that are easy for clueless users to go and mess up, thereby breaking the program and frustrating said user?
MS moved program settings to the registry to prevent that sort of thing from happening.
--Mike--
Ericahist [updated Oct 26] | CP SearchBar v2.0.2 | Homepage | RightClick-Encrypt | 1ClickPicGrabber
"That probably would've sounded more commanding if I wasn't wearing my yummy sushi pajamas."
-- Buffy
|
|
|
|
|
Michael Dunn wrote:
The files that are easy for clueless users to go and mess up, thereby breaking the program and frustrating said user?
Lol! I think it would be more dangerous if a user ran regedit instead.. 
--
The coolest game in the world: NHL Hockey[^]
|
|
|
|
|
Jörgen Sigvardsson wrote:
I think it would be more dangerous if a user ran regedit instead..
Yep, that's why you won't find a Registry Editor shortcut on the Start menu. 
I can just imagine it now...
<clueless-user>
hmm, I'm running low on space. What can I do to get rid of some of my old programs? hmm... "Registry editor" Let me see what's there. *clickety*
Aitch-kee-local-machine. Is that like my hard disk? Open it up... ah, "software" that must list the software I have on my hard disk. Open it... HOLY CRAP I have all this software installed? *deletes* There we go.
</clueless-user>
--Mike--
Ericahist [updated Oct 26] | CP SearchBar v2.0.2 | Homepage | RightClick-Encrypt | 1ClickPicGrabber
Kosh reminded me of some of the prima-donna programmers I've worked with. Knew everything but when you asked them a question; never gave you a straight answer.
-- Michael P. Butler in the Lounge
|
|
|
|
|
And what about all them aitch-kee-classes?
:a-million-voices-screaming-out-in-pain:
--
The coolest game in the world: NHL Hockey[^]
|
|
|
|
|
One other advantage of the registry not mentioned here is that it supports multiple users much more transparently.
Even without that, I don't see the problem. Why should the registry be off limits to "some scumbag programmer" but not the file system? Hell, why even allow programmers access to the operating system at all?
wogerdoger wrote:
If I want my computer to behave differently: I'll tell it...
Give me a f**king break. In your world every piece of software would come with a printed list of how to manually install it and a massive manual describing, in detail, every change the software would make to your system.
Besides, let's assume that files were used as they were in Windows 3.x. Do you believe for a nanosecond that developers would never dare modify an INI file they didn't own? The Registry was invented precisely because of all the horrible problems with INI files.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
I think you are just having difficulty in using the registry API.
|
|
|
|
|
Yeah, it can be a royal pain if you have no clue like this guy.
"We have done so much in the last 2 years, and it doesn't happen by standing around with your finger in your ear, hoping everyone thinks that that's nice." - Donald Rumsfeld
|
|
|
|
|
You two are evil.
I like it
--
The coolest game in the world: NHL Hockey[^]
|
|
|
|
|
My opinion pretty much matches what everyone else said.
To your support, if INI files were used, it would be much easier to back up the settings for a single program. If it's in the same folder as the program, that's one less piece of the program scattered all over your hard drive.
However, the registry is still a useful tool, because everything is in one place. I don't have to search all over my hard drive to figure out which file holds a certain program's settings. The registry also uses fewer files, so backing up all your programs' settings is easier. Also, two or more different software packages may need to use the same settings, so a central location is necessary.
|
|
|
|
|
wogerdoger wrote:
Why does Windows need a registry ?
COM
"The folly of man is that he dreams of what he can never achieve rather than dream of what he can."
"If you think education is expensive, try ignorance."
|
|
|
|
|
Thought this might belong in the lounge!
Thanks for the good points and info (esp. Hockey for the spell-check example and "polymorhpic executables". I guess it borders on self-modifying code).
I have never used (As in personally edited) an .ini file and have never run Regedit or toyed with the Registry API (Though after reading up on it, It doesn't look that hard).
I liked the comments about "the inexperienced" "playing" with ini files or worse, the registry. My point here is the application should provide the interface (i.e Tools | Options) to change the program's user settings. Anyone who goes into a (.ini) file and "changes stuff" should expect the program to behave in a not-so-qhkwbefnlkjqw <Restore-Backup> manner. Hey I have Word…but IE doesn’t go looking for the “I have a Spell-checker” Key! Is it in the settings…?
Cheers for the feedback.
If sex is a pain in the ass, then your name must be Joe Woodbury or Jason Henderson!
|
|
|
|
|
Hi
Does anyone have any experience creating toolbars with CToolBar where the width of each button varies? If someone could point me in the right direction it would be great.
Thanks in advance
Richard
|
|
|
|
|
Use the TBSTYLE_LIST style for the bar, and BTNS_AUTOSIZE for the buttons. I don't know if you can have different-width buttons for toolbars that don't have TBSTYLE_LIST.
--Mike--
Ericahist [updated Oct 26] | CP SearchBar v2.0.2 | Homepage | RightClick-Encrypt | 1ClickPicGrabber
There is a saying in statistics that a million monkeys pounding on typewriters would eventually create a work of Shakespeare. Thanks to the Internet, we now know that this is not true.
|
|
|
|
|
I am trying to subclass all buttons in all my dialogs, i have tryed a couple of soluions but nothing works, i have always a temporary handle.
I've tryed with FindWindowEx with "Button" in the class parameter but it doesn't work.
Has anybody an idea on how can i subclass all the buttons in all my dialogs at runtime ?
|
|
|
|
|
Why are you doing this? Are your buttons dynamically created or placed there with dialog editor?
CHAIGNEAU wrote:
I've tryed with FindWindowEx with "Button" in the class parameter but it doesn't work.
Maybe it's case sensitive try BUTTON
If you just have buttons, you could enumerate each window and change it's WndProc as you go.
If your buttons are all within a particular range of COMMAND id's you could also iterate each button control using GetDlgItem()
HTH
Cheers
I'm drinking triples, seeing double and acting single
|
|
|
|
|
My buttons are placed there with dialog editor.
I want to subclass dynamically all buttons in my application to draw them as i want without put a variable member in all my dialogs.
The className parameter of the FindWindowEx function is not case sensitive and i've tryed "BUTTON",i also get the className of a button and put it in this parameters but it still doesn't work.
How can you enumerate each child window of a dialog and now it's a button and then subclass them?
I don't want to change it's WndProc but change his class.
Thanx for your reply.
|
|
|
|
|
Honestly the easiest way to accomplish OWNERDRAW buttons is to derive a class from CButton and override it's DrawItem() and then use class wizard to associate each button with a Control member variable, then change each variable type from CButton to CYourOwnButton and whola!!! all yer buttons should be drawn the way you want
If you insist on using a more dynamic approach you could just make all your command ID's fall within a certain range of values and call GetDlgItem() return it's handle and subclass the control this way. Why would you use this approach though? Are you using SDK only...? Or just for efficiency?
HTH
Cheers
I'm drinking triples, seeing double and acting single
|
|
|
|
|
I want to build a generic framework to subclass all buttons. I can't use classwizard because my purpose is to not modify the existing app and to integrate this framework with less code as possible.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
