I'd like to read and write window registry in window xp and 7 by using vb6. I'm not much strong in vb6. I tried this below
Dim str As String
str = GetSetting("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines", "Text", "ImportMixedTypes")
My coding doesn't work. Please point out my missing.
You can't use GetSetting for that setting. That method is only for reading/writing configuration settings for your own application. If you want to read anywhere in the registry you have to use the Windows API function RegOpenKeyEx and friends.
Here's a Microsoft support article that explains how to do this (with sample code): How To Use the Registry API to Save and Retrieve Setting
Note that you will have to have permission to read the relevant place in the registry, I'm not
sure if you'll have access to that key so you'll have to try it out.
HKEY_LOCAL_MACHINE can cause permission problems. described in these article Microsoft API article
procedures works well if you will change HKEY_LOCAL_MACHINE to CURRENT_USER.
Related
I have been trying (with limited resources) to use VBScript and VBA commands to send keyboard functions to a remote citrix terminal. - This, as I've discovered is a known restriction and I've found various articles which give an alternative method via C++ and scancodes to overcome the restriction.
The main issue is, I don't have access to C++.
Is there a solution that will allow this with VBScripts and/or VBA?
I've considered many options, including using the windows virtual keyboard (this didn't work) and installing a virtual keyboard driver in windows (well out of my depth).
Here is one of the articles which discuses the scancodes, using C++:
http://www.codeproject.com/Tips/310817/SendKeys-using-ScanCodes-to-Citrix
I am at a loss and anyone who can help would be a super hero...If a super heroes' main appeal was to be a geek god. :)
Any help is appreciated!!!
Cheers.
****UPDATE****
Hello,
I've done a little more digging...
...The Citrix ICA Client terminal window isn't receiving the VBScript sendkeys commands but if I manually press alt in the terminal after executing the script (with a 2 second pause), for example:
*Set objShell = WScript.CreateObject("WScript.Shell")
WScript.Sleep 2000
objShell.SendKeys ("e")
objShell.SendKeys "(P)"*
The above can access the 'file', 'edit', etc menu options on the tool bar within the terminal window.
This to me suggests that the issue isn't a privilege issue and I'd think that there is perhaps hope yet for the sendkeys method?
Having looked further into this, there is some documentation re: ini file settings on the Citrix site with regards to Citrix ICA clients.
One of the articles can be found below:
http://support.citrix.com/article/CTX129166
I've had a play around and there does seem to be a few ini files which list keyboard mappings, DLL files, virtual key passthrough as well?
One of the sections of the 'module' ini file contained the following:
[KeyboardLayout]
(User Profile)=0x00000000
(Server Default)=0xFFFFFFFF
There were other codes, including various languages, British, US-International etc.
This was then followed by a list of DLL codes e.g:
kbduk.dll=0x00000809
And finally, Language IDs, e.g:
eng=0x00000809
I am guessing (hoping) that there would be a way to amend the ini settings that will allow for the sendkeys to be received in the terminal fields and not just the toolbar menus.
As before, any help is appreciated....I am slowly going insane over this one!!!
Cheers!
Bullet pointed solution
What is required:
On screen keyboard (OSK.EXE) windows app
VBScript (not essential but preferred by me as controling script)
VBA (to move the mouse)
Set OSK to receive 'hover' commands
Set VBA code to move mouse to specific co-ordinates
Use VBScript to control when specific subs from the VBA XLS file are run. - This can be set to run in the background without the requirement for manual opening of the file etc.
Set Citrix Xenapp terminal as active window and key presses should send!
Cheers all!
I have my application written in Delphi XE that works with PDF files. Applicaiton is Win32. On start I would like to ensure that there is my item in explorer context menu for PDF files. I would like to be able to specify whether it should be added for active user only or for all users (with UAC I will need to restart with Admin privileges but thats ok).
I started with How to associate a Delphi program with a file type, but only for the current user? and How to add item to windows explorer content menu in delphi? . I tested it with manual registry editing via regedit and it worked fine for "new" extensions. But for .pdf it is more complicated as it will be most probably already present in the registry.
On my PC the .pdf key is referencing AcroExch.Document . But adding shell/something subkey to the AcroExch.Document key is not working because it has CurVer subkey referencing to AcroExch.Document.7. However another PC with another verison of Acrobat had this names a little different. It is no problem for me to follow the CurVer reference but is that a correct approach? And what about situation where no PDF reader is installed, how should I name my keys so Acrobat won't overwrite them when installed?
But more pressing matter is in which root should I put my keys? How to associate a Delphi program with a file type, but only for the current user? is mentioning HKLM (Local Machine) and HKCU (Current user). Its seems rather straightforward but I am unable to set values in HKLM from Delphi. Strangely I can create keys:
var reg:TRegistry;
key := '\Software\Classes\'+keyname+'\shell\'+name+'\command';
reg.CreateKey(key);
but I am getting Access Denied when trying to write the actual value:
reg.OpenKey(key,false);
reg.WriteString('',command);
I am getting the same Access Denied exception even on WinXP, no matter if the applicaiton is running as Admin (Win7), I even tried to set permissions (Everyone full control) for the key via regedit (I can edit the value via regedit without problems). I tried creating the registry with different access modes, all with no luck:
reg := TRegistry.Create(KEY_WRITE or KEY_WOW64_64KEY);
reg := TRegistry.Create(KEY_ALL_ACCESS or KEY_WOW64_64KEY);
reg.Access := KEY_ALL_ACCESS;
reg.Access := KEY_WRITE or KEY_WOW64_64KEY;
reg.Access := KEY_ALL_ACCESS or KEY_WOW64_64KEY;
With HKCU everything works fine.
So I tried writing into HKEY_CLASSES_ROOT and it works and actually puts the keys exactly where I want (into HKLM) if running as Admin. But according to http://msdn.microsoft.com/en-us/library/windows/desktop/ms724475.aspx
The HKEY_CLASSES_ROOT (HKCR) key contains file name extension associations and COM class registration information such as ProgIDs, CLSIDs, and IIDs. It is primarily intended for compatibility with the registry in 16-bit Windows.
I do not like the note about the primary purpose being compatibile with 16-bit Windows. And the actual conditions where the changes will be written is more complicated than I would like.
So basically I have these questions:
What is the advantage of using AcroExch.Document and CurVer instead of pointing directly to AcroExch.Document.7? And what are the "best manners" when adding my keys into this structure? What about the case when the .pdf is not yet associated with anything?
Where should I put my keys and why I am not able to write into HKLM?
Edit:
The problem with Access Denied when writing to HKLM was caused by my error. I did use in previous code openKeyReadOnly and I did not notice that it will swtich the Access property to readonly for all subsequent calls.
To answer your other question, if Adobe is not installed yet then obviously the PDF keys will likely not exist in the Registry yet so you would have to create your own .pdf and ProgID keys so that you can attach your Shell command on it. If Adobe is installed afterwards, it is likely going to wipe out your keys and replace them with its own, so you would have to recreate your Shell command within Adobe's key structure. Your app can query the Registry to check for that condition periodically, such as at startup.
You have asked two separate questions. Since I know the answer to one and not the other, I'm going to answer just one. For future reference, I do recommend that you ask a single question at a time.
Where should I put my keys?
You are correct in discerning that you should not use HKCR. The documentation for HKCR says:
Class registration and file name extension information is stored under
both the HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER keys. The
HKEY_LOCAL_MACHINE\Software\Classes key contains default settings that
can apply to all users on the local computer. The
HKEY_CURRENT_USER\Software\Classes key contains settings that apply
only to the interactive user. The HKEY_CLASSES_ROOT key provides a
view of the registry that merges the information from these two
sources. HKEY_CLASSES_ROOT also provides this merged view for
applications designed for previous versions of Windows.
....
If you write keys to a key under HKEY_CLASSES_ROOT, the system stores
the information under HKEY_LOCAL_MACHINE\Software\Classes. If you
write values to a key under HKEY_CLASSES_ROOT, and the key already
exists under HKEY_CURRENT_USER\Software\Classes, the system will store
the information there instead of under
HKEY_LOCAL_MACHINE\Software\Classes.
So, it is reasonable to use HKCR for reading, but for writing you typically need to exert control over whether to write to HKLM or HKCU. And that means that you cannot write to HKCR.
So, write to HKLM\Software\Classes for machine-wide settings, and HKCU\Software\Classes for user-specific settings.
Note that in Windows 7 and later neither of these keys is redirected and so you do not need to worry about using KEY_WOW64_64KEY. However, in Vista and XP64, and the equivalent server editions, these keys are redirected and reflected. Which means that it might be prudent to use KEY_WOW64_64KEY.
How do I read a particular vb program settings or registry entry from the registry of the key "HKEY_USERS\S-1-5-21-1390067357-1965331169-725345543-1003\Software\VB and VBA Program Settings".A standardized way to read as the part after hikey_users and before software changes with the pc used,but the vb programs do write perfectly at the right place.Is there some variable that defines the registry key location ?
VB6 has built-in functions for manipulating the registry, like GetSetting. These functions use registry keys underneath HKEY_CURRENT_USER\Software\VB and VBA Program Settings
HKEY_USERS\S-1-5-21-1390067357-1965331169-725345543-1003\Software\VB and VBA Program Settings is just another path to the same set of keys: the long string in the middle identifies the current user by their ID, rather than just saying "the current user".
So the answer is:
If you are using VB6, just use GetSetting.
If you are using VBScript, use WshShell.RegRead and work on HKEY_CURRENT_USER\Software\VB and VBA Program Settings. Example code in this article.
I have figured out how to change the desktop wallpaper (there are dozens of examples on the Internet.)
One thing that still eludes me: how do I detect when the wallpaper has changed? (Say via the Display control panel or another program changing it.)
Add a message handler for WM_SETTINGCHANGE, SystemEvents.UserPreferenceChanged in .NET. Check if the wallpaper is still the same.
Here is an example in C# to retrieve the wallpaper. All you would need to add is some additional code to store the last wallpaper and check to see if it is different.
RegistryKey wallpaper = Registry.CurrentUser.OpenSubKey("Control Panel\\Desktop",false);
string wallpapername = wallpaper.GetValue("wallpaper").ToString();
wallpaper.Close();
If you were writing something in a non .net language you could use the Win32 API RegNotifyChangeKeyValue function to check to see if this value has changed:
HKEY_CURRENT_USER\Control Panel\Desktop\Wallpaper
How can I use multiple keys in WSH Script like (ALT,CTRL,DELETE)?
How can i take a screenshot of an application and paste it in MSWord using WSH SCript?
Using SendKeys, you can't. I told you so.
Regarding sending multiple keys - please read the documentation on SendKeys() on MSDN. It's not hard to find out.
Maybe there is an ActiveX component somewhere that can take screen shots for you, but using vanilla Windows scripting, this cannot be done.
Yeah I think like Tomalak said, what you're trying to do will most likely involve invoking an ActiveX component using the CreateObject command.
I'd advise against it though, usually when you hit the point where your script is trying to invoke applications (Word) and take screenshots... it's time to invest in some development software (Visual Studio or something) and write an actual application.
If you're totally set on it though, DevGuru has a decent reference page for the CreateObject command.
https://social.technet.microsoft.com/wiki/contents/articles/5169.vbscript-sendkeys-method.aspx
It says that to do something like "Alt F5", to do "% {F5}"
To do Ctrl Alt Delete, you have to do "^ % {DEL}"