 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
VB Forum / Win API / September 2008Scheme name and OS
Hi. How to find out the current scheme name and the OS name by means of Win32 API? Thanks in advance. > Hi. > > How to find out the current scheme name and the OS name by means of Win32 API? I have no idea what you mean by the current scheme name. As for the OS name: http://msdn2.microsoft.com/en-us/library/ms724429.aspx How much or little of that sample you use is up to you :)  SignatureDean Earley (dean.earley@icode.co.uk) i-Catcher Development Team iCode Systems Thanks, Dean. But I'd rather to correct the question. I need to find out whether the XP-schema is used or not. (In any OS - WindowsXP, Vista, 2003Server...) So, how to find out the schema name? Ivan. > Thanks, Dean. > > But I'd rather to correct the question. > I need to find out whether the XP-schema is used or not. > (In any OS - WindowsXP, Vista, 2003Server...) > So, how to find out the schema name? I still don't know what you mean by the XP scheme or schema. If you mean the Windows themeing and visual styles, you can use IsThemeActive() and IsAppThemed() functions. For the name, the obviously named GetCurrentThemeName() function. SignatureDean Earley (dean.earley@icode.co.uk) i-Catcher Development Team iCode Systems Do you mean Themes, like whether the XP skin is showing, as opposed to "classic mode"? If so, there are settings in the Registry to figure out (1) whether any theme is active: HKCU\Software\Microsoft\Windows\CurrentVersion\ThemeManager\ThemeActive dword 1=active (2) which theme it is: "HKCU\Software\Microsoft\Windows\CurrentVersion\ThemeManager\DLLName" string. value data contains "Luna" for default theme. and (3) which color option in the theme is active: "HKCU\Software\Microsoft\Windows\CurrentVersion\ThemeManager\ColorName" string. default theme of blue/green has value data of "Normalcolor". If silver is showing value data is "Metallic". For olive theme value data is "Homestead". > But I'd rather to correct the question. > I need to find out whether the XP-schema is used or not. > (In any OS - WindowsXP, Vista, 2003Server...) > So, how to find out the schema name? > > Ivan. > Do you mean Themes, like whether the > XP skin is showing, as opposed to "classic [quoted text clipped - 18 lines] > If silver is showing value data is "Metallic". For olive theme value data > is "Homestead". NOOOOOOOOOOOO!!! Whatever you do, DON'T read this stuff from the registry, when there are fully documented API calls to do this properly!! People reading from the registry instead of using documented APIs is the cause for most of the cruft it contains. SignatureDean Earley (dean.earley@icode.co.uk) i-Catcher Development Team iCode Systems > > Do you mean Themes, like whether the > > XP skin is showing, as opposed to "classic [quoted text clipped - 23 lines] > Whatever you do, DON'T read this stuff from the registry, when there are > fully documented API calls to do this properly!! The reason I read the Registry is because that's where the information is stored. Where do you suppose your official API call gets the data from? It's just a wrapper for the read I posted. > People reading from the registry instead of using documented APIs is the > cause for most of the cruft it contains. ?? I never talked about *writing* to the Registry. Whatever "cruft" is, it's not added to the Registry as a result of reading a value. I actually researched and worked out the Registry values for this at one point because I needed to find out the theme status via VBScript. VBScript does not have access to APIs, but it can read the Registry. In any case, if you know of APIs for returning the current theme status more conveniently then perhaps you could post the details. Wouldn't that be more useful than posting superstitions and hearsay about the alleged "birth of cruft"? >>> Do you mean Themes, like whether the >>> XP skin is showing, as opposed to "classic [quoted text clipped - 28 lines] > official API call gets the data from? It's just a wrapper > for the read I posted. But is it documented as being stored there? The setting may be cached internally and not written out immediately and MS are free to change its location or format at any time. I'd happily bet that the contents of those values you mentioned are different on Vista (or ignored for compatibility)... >> People reading from the registry instead of using documented APIs is the >> cause for most of the cruft it contains. > > ?? I never talked about *writing* to the Registry. > Whatever "cruft" is, it's not added to the Registry > as a result of reading a value. http://blogs.msdn.com/oldnewthing/archive/2003/11/03/55532.aspx Covers it very well and far better then I could. > I actually researched and worked out the Registry > values for this at one point because I needed to find out [quoted text clipped - 6 lines] > than posting superstitions and hearsay about the alleged > "birth of cruft"? I mentioned all 3 relevant API calls in my post 3.5 hours before your reply. Message-ID: <u08T$dBDJHA.3392@TK2MSFTNGP03.phx.gbl> SignatureDean Earley (dean.earley@icode.co.uk) i-Catcher Development Team iCode Systems > I mentioned all 3 relevant API calls in my post 3.5 hours before your reply. > Message-ID: <u08T$dBDJHA.3392@TK2MSFTNGP03.phx.gbl> Woops. I missed that. Personally, though, I think I'd be inclined to stick with the Registry read in this case. (The Shell Folders post was an interesting read, but not really the same issue.) When I did a search on the theme API methods it turned out that IsThemeActive is for the calling program, not necessarily answering the system status. This link was a discussion about how the return can vary depending on how the program was started: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2666475&SiteID=1 >> I mentioned all 3 relevant API calls in my post 3.5 hours before your > reply. [quoted text clipped - 13 lines] > > http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2666475&SiteID=1 I suggest you re-read that post you point to. It says "The main problem is that the program is started from a local service before a user is logged into vista." So how exactly do you propose to read from HKCU in that circumstance ? You do realize that HKCU is the "current user" in the registry, right ? > I suggest you re-read that post you point to. It says "The main problem is > that the program is started from a local service before a user is logged > into vista." > > So how exactly do you propose to read from HKCU in that circumstance ? > You do realize that HKCU is the "current user" in the registry, right ? Good point. I just noticed one of my first search links was talking about a problem with IsThemeActive. Actually I thought that Dean Early made good points. It was the adamant rule-bound approach I was questioning; the attitude that it's always better to follow rules than to use one's own judgment. I meant the link as an example of how it's not a black-and-white issue when it comes to Microsoft's officially suggested practices. (In the case of theme settings I found those by using Regmon to track where the Display applet was getting its info. Those Registry values seem to be the official place to store that info.) A good example of things are not black and white when dealing with Windows programming is actually related to the Shell Folders key problem. (Discussed in the Raymond Chen link.) I always use the APIs for folder paths when possible because as far as I know there's no standard Registry key for those. Yet the CSIDL methods won't return the Program Files folder on Win9x. (SHGetSpecialFolderLocation and the more recently recommended SHGetFolderPath both fail.) I'm not sure they even work on NT systems for that folder. The only way I know to find the path is from: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ "ProgramFilesDir" I don't think that's official. I guess I'd have to call it a "crufty Registry hack". :) But it seems to work on all systems, and that's what matters. Another good example is the Vista problem with GetVersionEx. If a program is started by another program running in compatibility mode then a call to GetVersionEx will return wrong data. Is that a bug? Or maybe MS just doesn't think I need to know what version I'm running on? I don't know. Whatever it is, I have software that I don't want to run on Vista, in any mode. So I have to cook up a non-official solution in order to get the job done. Naturally I get impatient when someone blurts out that NOOOOOO, you should never do that. That's like people standing on the deck of a sinking ship, after the captain's made his escape, shouting, "No! No! You're not supposed to lower the life boats until the captain says so!" Such people would rather drown following orders than risk trusting their own judgment. As for broken compatibility in the future, that's always true. Anything has to be tested on a new system before it's used. Whatever method is used to get theme info., it has to be tested on Vista if someone wants to support Vista. It would be crazy to just assume that Microsoft didn't break anything moving forward. >> I suggest you re-read that post you point to. It says "The main problem > is [quoted text clipped - 6 lines] > Good point. I just noticed one of my first search links > was talking about a problem with IsThemeActive. Yes but the link you found applies either way as I pointed out to you. IOW: you probably didn't read it properly or think about it, instead you posted it as a defense for using a registry hack, when clearly the registry hack would have the same if not more problems. Not sure if it translates to there, but here that's usually called a "red herring" . > Actually I thought that Dean Early made good points. Yes he did/does. > It was the adamant rule-bound approach I was questioning; > the attitude that it's always better to follow rules than to > use one's own judgment. Dean said : "Whatever you do, DON'T read this stuff from the registry, when there are fully documented API calls to do this properly!!" You seme to not be reading what he said, especially the qualifying part of the sentence. > I meant the link as an example of > how it's not a black-and-white issue when it comes to > Microsoft's officially suggested practices. Well it wasn't. So perhaps some more thought before posting would have helped ? > (In the case of > theme settings I found those by using Regmon to track > where the Display applet was getting its info. Those Registry > values seem to be the official place to store that info.) It is NOT the official place to store that information. The *official* way to read that information is via the documented API. > A good example of things are not black and white when > dealing with Windows programming is actually related to the [quoted text clipped - 13 lines] > it a "crufty Registry hack". :) But it seems to work on all > systems, and that's what matters. See : http://vbnet.mvps.org/index.html?code/browse/csidl.htm Note the "best practice" comment Randy put on the title. I won't rehash all past conversation on this, suffice it to say exactly what Dean said : "Whatever you do, DON'T read this stuff from the registry, when there are fully documented API calls to do this properly!!" If, and only *if*, the fully documented API calls don't do it properly for you, then and only then resort to registry hacks. > Another good example is the Vista problem with > GetVersionEx. If a program is started by another program [quoted text clipped - 4 lines] > want to run on Vista, in any mode. So I have to cook up > a non-official solution in order to get the job done. Well I would call that an example of why you should use GetVersionEx, so that the end user does get to set compatability mode. > Naturally I get impatient when someone blurts out that > NOOOOOO, you should never do that. Well don't. Take your time, breathe, and digest what is written. There's no race for a retort needed. > That's like people > standing on the deck of a sinking ship, after the captain's > made his escape, shouting, "No! No! You're not supposed > to lower the life boats until the captain says so!" Such people > would rather drown following orders than risk trusting their > own judgment. That's another "red herring". Dean's advice was solid and good. > As for broken compatibility in the future, that's always > true. Anything has to be tested on a new system before > it's used. Whatever method is used to get theme info., it > has to be tested on Vista if someone wants to support Vista. > It would be crazy to just assume that Microsoft didn't > break anything moving forward. Sure but you can't expect and support for using undocumented hacks. Microsoft actually has an incredible brilliant track record of supporting it's documented API, especially compared to other vendors. In the cases where they do break the API they also just about always document that change either in the API documentation and/or in KB articles. SO finding a solution also gets a lot easier should you have to deal with those kind of changes. I suppose I'll probably regret trying to respond to your endless twisting of meanings, but for the sake of clarity in this thread, maybe I should try to at least straighten out a couple of kinks... > > (In the case of > > theme settings I found those by using Regmon to track [quoted text clipped - 3 lines] > It is NOT the official place to store that information. The *official* way > to read that information is via the documented API. ---------- That's two different things: The official place to store/retrieve the theme info. and the official way to retrieve it. You didn't give an explanation for the statement that it's not the official place to store theme info. (The official way to retrieve it is another matter.) Are you saying that the Registry settings I listed are a willy nilly bunch of arbitrary bloat that Windows does not use consistently? And that the real settings are perhaps in some INI file somewhere? If you know for certain then maybe you could tell us so we can all do this hack right. :) ---------- > > A good example of things are not black and white when > > dealing with Windows programming is actually related to the [quoted text clipped - 18 lines] > > Note the "best practice" comment Randy put on the title. > I won't rehash all > past conversation on this, suffice it to say exactly what Dean said : [quoted text clipped - 3 lines] > If, and only *if*, the fully documented API calls don't do it properly for > you, then and only then resort to registry hacks. ------------- You're not answering to what I wrote. If you re-read it you'll see that it's an example of how the API doesn't serve. ...Yet you want to send me to a link for documentation on that same API. The official MS "best practice" won't tell me the Program Files folder path on Win9x and I'm not sure it even works on NT versions. (I don't remember offhand.) The Registry read does seem to work. (If it ever fails I haven't found the case, so it's at least more dependable than the MS "best practice".) That's it. Very simple. The fact that Randy Birch has documented the "best practice" method has nothing to do with anything! ------------ > > Another good example is the Vista problem with > > GetVersionEx. If a program is started by another program [quoted text clipped - 7 lines] > Well I would call that an example of why you should use GetVersionEx, so > that the end user does get to set compatability mode. -------------- No. Once again you're not answering to what I wrote. I don't want the software to run on Vista. Period. The GetVersionEx "bug" means that GetVersionEx is not adequate to achieve that. Simple as that. (Perhaps you think I have no right to not support Vista? That's not for you to say.) This is not about respecting or not respecting Microsoft. It's not about "behaving" or cutting corners. It's not an emotional issue or a loyalty issue or a religious issue. It's about getting the job done in Windows. That's it. Simple. And the best way to do that is to know as much as possible about how Windows works, both the official operation and the actual. > I suppose I'll probably regret trying to respond to > your endless twisting of meanings Mayayana, this "retort" of your is totally inappropriate. I'm not even going to dignify the rest of your response with a detailed reply. You posted here saying to use the registry, Dean posted saying to use the API. You then attacked Dean demanding he post the API when he had already. You then dig up some post you find somewhere and try to paint that as a reason not to use the API. I again corrected you and pointed out that the in that case you claimed, the registry hack would have made no difference. OS then you go on trying to find other fringe cases, deliberately twisting what was said. Here, let me again post *exactly* what Dean said: > "Whatever you do, DON'T read this stuff from the registry, when there are > fully documented API calls to do this properly!!" And here, is what I said: > If, and only *if*, the fully documented API calls don't do it properly for > you, then and only then resort to registry hacks. So unless you can actually give a *REAL* reason not to use the API detecting if themes is on, then I suggest you give it a rest. And please learn to chill out some and stop with the personal attacks everytime you get something wrong. An interesting, ironic addendum to the discussion on the various CSIDL methods and Registry hacks: As I'd said, I use the method of reading the "ProgramFilesDir" Registry value for the Program Files path because I found the CSIDL methods don't work on at least some systems, perhaps on all. The place I use that code is in my own rebuilt version of Setup1.exe and I've never had any complaints. Now, looking at the original version of setup1.exe, it turns out that that's where I got my method in the first place. Microsoft programmers used that method in the VB6 Package and Deployment Wizard setup program. :) (ResolveDestDir function in Setup1.bas) > > > A good example of things are not black and white when > > > dealing with Windows programming is actually related to the [quoted text clipped - 40 lines] > The fact that Randy Birch has documented the "best practice" > method has nothing to do with anything! > An interesting, ironic addendum to the discussion > on the various CSIDL methods and Registry hacks: [quoted text clipped - 10 lines] > > (ResolveDestDir function in Setup1.bas) The PDW based setup isn't exactly the best model for good programming :) As is said repeatedly, Microsoft teams are just about as bad as non MS developers, and very few of them have any privileged access to anything more than we do as "general public". SignatureDean Earley (dean.earley@icode.co.uk) i-Catcher Development Team iCode Systems > In any case, if you know of APIs for returning the > current theme status more conveniently then perhaps > you could post the details. He did already, long before you posted. And Dean is quite correct you should use the API, not read directly from the registry. That's why the API is actually called "API". >> Do you mean Themes, like whether the >> XP skin is showing, as opposed to "classic [quoted text clipped - 25 lines] > People reading from the registry instead of using documented APIs is the > cause for most of the cruft it contains. I see your point of how MS could, in the future, reorganize the Registry settings. Therefore, I'm in agreement with you that the API functions designed specifically for this purpose are better to use. Especially since if they are just "wrappers" to read the info from the Registry, they'd probably get updated to still function properly in later versions of Windows should MS change things. However, I see no harm in simply READING these from the Registry if one is inclined to go that route. They just need to be prepared that in a later version of Windows, these settings might not exist in the Registry or might exist elsewhere. And... how does this add "cruft" (never heard of that word, but from context, I'm guessing it means "junk" or "excess"?) to the Registry? It's MS that's writing the stuff to the Registry. And I kinda doubt they're thinking was "we gotta put this in the Registry because programs are going to want to read it from there". <g> SignatureMike Microsoft MVP Visual Basic >>> Do you mean Themes, like whether the >>> XP skin is showing, as opposed to "classic [quoted text clipped - 36 lines] > version of Windows, these settings might not exist in the Registry or might > exist elsewhere. Only the fact that it is more effort to read the registry vs a single API call and is potentially less reliable. > And... how does this add "cruft" (never heard of that word, but from > context, I'm guessing it means "junk" or "excess"?) to the Registry? It's MS > that's writing the stuff to the Registry. And I kinda doubt they're > thinking was "we gotta put this in the Registry because programs are going > to want to read it from there". <g> That is exactly what they've had to do because of that reason. Check the article I linked to by Raymond Chen :) I have no idea how many other things use the same ideas or whether they learnt from it though. SignatureDean Earley (dean.earley@icode.co.uk) i-Catcher Development Team iCode Systems |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.