I am running Win7 and wish to change the build identifier displayed when setting HKCU\Control Panel\Desktop\PaintDesktopVersion to 1.
Is there a possibility to change this text, or to add to it (for example a name of the personal computer or a name of the user)?
Like David said, the string is hardcoded. The good thing is, there already exists a great utility that adds text to the wallpaper.
There's no API to control what gets displayed. You can hack the resources of user32.dll.mui to change the text if that's the kind of thing you like doing. Modifying the wallpaper would be a more reasonable approach in my view.
Related
is there any way to find out the current theme color set for the Modern UI? A WinAPI function or registry value would be the best possible solution for me.
By current theme color i mean this.
There's a private function called GetImmersiveUserColorSetPreference in UxTheme.dll. If you set the first parameter to true, it should use the value from the registry that GameScripting mentioned (and notify the system of the change).
I wrote about retrieving immersive/modern/metro colours here. Keep in mind that you won't be able to use these undocumented functions in WinRT Windows Store Apps, since they'll fail certification.
After reverse engeneeing my system using procmon.exe, I've figured out that the registry key under the path HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Accent\ColorSet_Version3 seems to be the selected color.
I can read and write to it using the registry editor (regedit.exe) and all changes get applied immediately.
EDIT: After some further research, it seems to be read only, changed don't get applied "anymore". There seems to be anything at path HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SystemProtectedUserData\S-1-5-21-3552576858-2522621019-3615910227-1001\AnyoneRead\Colors\ImmersiveColorIndex_Version3 but I can't manage to change the value (even with admin rights)
I'm trying to programmatically check file associations by the file extension (for example .jnlp files). I keep reading that
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\JNLPFile\Shell\Open\Command
is the Registry key to check. However, if you change the association through Windows Explorer:
Open With > Choose Program > (Always use the selected program)
the change isn't at all reflected in this Registry key. Where else is this information stored?
Take a look in:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\
and the sub-key of that is the extension you reassigned. Under that there will be the UserChoice and OpenWithList sub-keys which will contain your redefinition.
You may also want to read http://support.microsoft.com/kb/950505 which talks about your issue.
Update
As of Windows 8, life has gotten far more complicated. To create an extension association a custom hash needs to get calculated.
Fortunately, someone has reverse engineered the process and created a PowerShell script to do this without having to go through any GUI.
You can find it at the following GitHub link:
https://github.com/DanysysTeam/PS-SFTA
This is a two-part look-up.
First, you look up the default value of HKEY_CLASSES_ROOT\[file_extension]. For your extensions, .jnlp, the value is "JNLPFile". Let's call this the [file_descriptor].
Now you can look up the default value of HKEY_CLASSES_ROOT\[file_descriptor]\Shell\[action]\command (where [action] is the shell action you are interested in, e.g.: Open, Print, Edit, etc.).
On:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.jnlp\OpenWithList
Tip: Edit>Find is pretty handy at these situations. :)
In PowerBuilder's IDE, the code autocomplete feature uses the clipboard to communicate the completed text to the code window. By doing so, it overrides whatever was stored on the clipboard before. So, if you had the winning numbers of the next lottary stored on your clipboard, and you used the autocomplete to turn m_goodfor into m_goodfornothing, you've just lost your only chance of ever getting rich, and you're left with nothing on your clipboard.
Features like that are the reason I hate software. It looks like it was implemented by some intern that noone was looking after. However, there's also a chance I got all worked up for nothing, and making such use of the clipboard is absolutely legit. So, can an app use the clipboard for its own purposes? Who is considered the owner of the clipboard?
(Bonus votes to whoever puts himself in place of the feature's programmer, and provides some reasoning for this being done on purpose, assuming the users would actually benefite from it)
You are probably right on the intern reasoning. There is absolutely no reason why an application would use the clipboard to communicate information other than pure laziness. Even between processes, there are other, better ways of communicating information.
Other then letting the user paste information in another application, there is no reason to use the clipboard.
The programmer did it because it was easy, and put his needs above those of the end user. There are many programs that do this, particularly add-ins to outlook, VB, etc., which copy/paste their buttons onto the toolbar. Any user that runs a clipboard extender (like my own ClipMate) will absolutely hate this behavior (and you'll be "busted" right away).
Here is my favorite quote on the subject:
“Programs should not transfer data into our out of the clipboard without an explicit instruction from the user.”
— Charles Petzold, Programming Windows 3.1, Microsoft Press, 1992
An app should never change anything on the clipboard without the user initiating that action. My .02 anyway.
Bonus votes to whoever puts himself in place of the feature's programmer, and provides some reasoning for this being done on purpose
Using clipboard for application communication
They are always a better way to do it. The programmer might have done it this way because it was faster to implement OR because he really wanted to have this value in the clipboard after the action. At least, if he didn't wanted to have it in the clipboard he could have get the value from the clipboard, store its value then replace the old content of the clipboard inside the clipboard and everything would have be more "transparent" ans less frustrating for the end-user.
I have built a piece of functionality into an App that uses the clipboard. Business was requesting a way for users to seamlessly capture a screen shot and upload it.
I worked with the business to develop it and what we came up with was a user simply hit the print screen key and clicked "upload" in my app.
The Java Applet running in the background pulled the image off the clipboard and displayed a formatted preview to the user, The user then added in a file name and description and clicked save.
Using the clipboard this way saved the user the time of having to capture the screen shot save it somewhere then find it through an upload interface. Even if we did go that route by the user hitting print screen to capture the image in the first place they are already overwriting whatever was on the clipboard in the first place.
Using the clipboard isn't all bad but I certainly agree using it in an IDE is a def no no.
One of my programs seems to be changing the Display Properties > Appearance > Effects > Show window contents while dragging setting to off every few hours.
I'm not sure exactly which program, or when it happens. I have a number of programs that seem like likely culprits - wallpaper rotators, software for multiple monitors, multiple virual desktops and switching, and a few others.
I am just thinking to create a little batch script to run periodically and set the setting back to on.
Does anyone know how to do this in windows? I'm using xp pro sp3.
Thanks!
The best option is to do this programmatically using the supported API. i haven't tested this, but it should do the trick:
SystemParametersInfo(SPI_SETDRAGFULLWINDOWS,
TRUE,
NULL,
SPIF_UPDATEINIFILE | SPIF_SENDCHANGE)
You can use SPI_GETDRAGFULLWINDOWS to see if the the bit has been flipped to avoid unnecessarily triggering a WM_SETTINGCHANGE.
You can use RegMon to find the program that keeps changing your settings. Maybe that's a better start than hacking around it.
There is a simple and effective solution to this problem. In Notepad type the following lines :
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Control Panel\Desktop] "DragFullWindows"="1"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VisualEffects\DragFullWindows] "CheckedValue"=dword:00000001 "UncheckedValue"=dword:00000001
Save the file as "Show Window Contents.reg" Double clicking this file and restarting will cure the problem permanently. Post a message if you find this useful.
Aravind Banerjee
It seems the registry setting which controls that preference is HKCU\Control Panel\Desktop\DragFullWindows. You can read more about it here. However, trying it on my own computer does not register the change right away, so a batch script won't do it. You'll probably have to write a program to manipulate it using SystemParametersInfo(). You can pass it the SPI_SETDRAGFULLWINDOWS parameter. Here's a page explaining it more. Here's a page showing how to call it, albeit not for the same parameter.
I suspect it's kept in the registry - maybe [HKEY_CURRENT_USER\Control Panel\Desktop] - "DragFullWindows"?
It would be easy to flip the registry setting back to "1" every hour or so with a batch file.
We're using the file picker dialog to allow users to add documents into our application. The word 'Open' doesn't make a lot of sense in this case.
Thanks.
I would browse the code found here, which shows how someone extended the OpenFileDialog. Admittedly, this is overkill for you. But I think there is code within to change the button label.
Not really no.
Given the standardization of this dialog it's extremely likely that your users will have used it many times in the past to "add" files to applications. The chances are they will be quite familiar with the implications of the word, changing it may be more confusing to them.
The standardness of the dialog is why it's called a "Common File Dialog". If you want to change it for your app, you'll have to write your own dialog.
Having said that, there are apps out there that can pull a form out of a DLL, modify it, and stick it back in. However, this is a per-machine hack and downright bad form.