I am currently reworking an Intranet Website using Active Directory, and the ancient developer did everything in VB, I am now developing it in C# and a bunch of recent technologies. So I am going through his code for a few functionalities I'm having a hard time with (I did a quick overview of VB to see how it works globally) and I don't understand how strings work here.
For example, there is the following declaration:
Dim sGroups, oGroup
sGroups=activeDirectoryUserObject.memberOf //Returns groups that user belongs to
set oGroup = GetObject("LDAP://" & sGroups)
For j = 0 To UBound(sGroups)
Set oGroup = GetObject("LDAP://" & sGroups(j)) //Here!!
What is sGroups(j)? To me sGroups is a string not an array, so what's going on here?
Thanks for your help!
Leonard:
It appears that sGroups(j) is a string and that the (j) part is a counter. Possible that this is being used if the user belongs to more than one group.
Sincerely,
Joe
Strings are not indexed in VBS/VBA/VB6. And the method of indexing is different in VB.NET. So if the object is indexed, "sGroups(j)" it's not a string.
The obvious way to work out what sGroups is, would be to look at activeDirectoryUserObject and it's memberOf attribute. Which you should have done, and you should have included that code here, so that we could see it.
If it's an externally defined object, for which you have no documentation, you can use the Typename() function or VarType function to extract the information. Since this is a website using ASP scripting, either it's going to be a variant array, or the script is completely broken.
Either is possible, since the script fragment you have provided makes no sense by itself (see also the redefinition of oGroup with no code that uses it).
I'm completely rebuilding a shared iTunes library and this needs to be team work.
I found a way to work the XML database in Google Drive so that we can all edit the track list simultaneously (>7500 entries). The spreadsheet contains for every song the path to the corresponding file.
Now I need a script to move the tracks listed in that spreadsheet to a common folder, so I can separate the songs we decided to keep from the ones we don't want anymore.
The blueprint I imagined for the code is basically :
Get the paths list (txt, csv, etc. doesn't matter) and store it as
an array.
Rotate through that array and select+move to a common folder each file pointed by the paths.
I'm not expecting any ready-to-use solution, but I would really appreciate some tips or pieces of advice that could make me spare a lot of time.
I also have to admit I have limited knowledge in Mac OS X programming (more used to web and windows environments) and have no experience in Applescripts.
However, I feel that what I'm trying to achieve is pretty straightforward and could help other people as well.
there are just 2 items not clear in your request :
1) what is the file type in which file paths are stored ? I assumed it is a text file
2) which format the paths have ? is it Unix format (like HD/Users/My_User/Desktop/My_Song), or is is a Finder format (like HD:Users:My_User:Desktop:My_Song). I assume it is a finder format
then script bellow asks you to select the text file, read it, ask you to select destination folder and move every file described in text file to the destination folder.
tell application "Finder"
set TextFile to (choose file with prompt "Select your text file" of type {"txt"})
set My_Folder to choose folder with prompt "Select your destination folder"
set List_files to paragraphs of (read TextFile)
move List_files to My_Folder
end tell
the "move" can be changed to a "copy", if required
Thank you so much to both of you for your answers.
Regarding pbell's questions :
1. I did not specify the format of the file containing the paths because I wasn't sure which ones the script could handle. Now I will make sure it is in a txt format.
2. The paths are actually il a Unix format, but seeing your example it looks pretty easy to parse. Can I just replace every "/" with a ":" ..?
I will try your code this afternoon. Again thanks a lot for caring and for sharing your time and knowledge.
Terence
Works like a charm !
Thank you very much pbell, your code works perfectly. I just had to make a txt file with Finder-formatted paths like so :
Macintosh HD:Users:FirstnameSurname:Desktop:Music:November-7:Season 3:04 Parasite.mp3
Macintosh HD:Users:FirstnameSurname:Desktop:Music:November-7:Season 3:05 Nowhere.mp3
Macintosh HD:Users:FirstnameSurname:Desktop:Music:November-7:Season 3:06 Amber Light.mp3
We spared so much time thanks to you.
Have a great day,
Terence
I'd like to have my VBScript display the Windows Save As dialog box, but I could not find out how to do it.
Using this code:
Dim sfd
Set sfd = CreateObject("UserAccounts.CommonDialog")
sfd.ShowOpen
I can get an Open dialog, but there is no ShowSave method for this object (as there seems to be for a similar object in Visual Basic non-script).
I searched StackOverflow and googled for "[vbscript] save dialog" (and with "Windows Script Host"), but I only found threads about accessing common dialogs from web pages and a solution for the BrowseForFolder dialog and nothing really about calling the Save dialog.
Actually, I can use the Open dialog for my purpose, because all I need is a file name... but as I'd like to save something to the selected path, a "Save As" in the title bar of the dialog would be more appropriate.
The secret to using the common dialog from VBScript (or VBA or JScript, for that matter) is that you have to have its license installed on your machine. Certain development tools, such as Visual Basic 6, will install the license, but it's also installed by the free Microsoft HTML Help Editor (this is a pretty old app). The interesting thing is that if you install and then uninstall the HTML Help Editor, it leaves the Common Dialog License in place. For this reason I would consider the license to be freely available and so will include the registry entry it creates here in my answer:
In HKLM\Software\CLASSES\Licenses\4D553650-6ABE-11cf-8ADB-00AA00C00905, set the (Default) entry to gfjmrfkfifkmkfffrlmmgmhmnlulkmfmqkqj.
Once that's in place, you can create these dialogs from within a VBScript using code like this:
Set objDialog = CreateObject("MSComDlg.CommonDialog")
To launch a file save dialog, use the ShowSave method as in this code:
objDialog.ShowSave
Of course this object has a bunch of other methods and properties, and you'll probably want to configure the appropriate properties before launching the dialog. For example, you can set the file filter so only certain file extensions are shown in the dialog. There's a nice reference to the control on the MSDN site here: http://msdn.microsoft.com/en-us/library/aa259661%28v=vs.60%29.aspx.
Hope this helps. Let me know if you have any questions.
I can definitively say that there is no solution to show a Save As dialog box from VBScript under versions of Windows other than XP without relying on some external dependencies that you must install and register yourself. Aside from the obvious interference this causes with regards to an easy, drag-and-drop deployment of your script, it also brings up a whole host of other issues related to security and permissions, particularly by-passing UAC on the client's machine to install and register a dependency DLL.
The solutions that have been proposed so far rely either on a DLL file that just so happens to be included with Windows XP, invoking the Save As dialog box from Windows XP's User Accounts control panel, and/or installing a piece of software only for it to leave behind the MSComDlg DLL after it is uninstalled that you can then use from a VBScript. None of these solutions truly satisfy the above requirements, and none of the provided answers has even considered the possible security roadblocks that would arise with their proposed solutions, as I alluded to above.
And since you can't make calls directly to the Windows API (which ever-so-conveniently includes just such a Save As dialog) from VBScript (not only because it would pose a security risk, but also because of VBScript's loose [lack of?] typing), that pretty much leaves anyone wanting to do this out in the cold. As well, the inability to make API calls also precludes the use of any hacks like calling SetWindowText to change the caption of the Open dialog, as suggested in the question.
I realize that this is not the answer everyone was wanting. It's not even the answer I was wanting. But alas, it's the correct answer.
That being said, here are a couple of possible workarounds:
If you're leaning towards accepting any of the already-suggested answers, you've already decided to introduce an external dependency on a DLL file to your VBScript deployment. Once you've made that leap, why bother with "borrowing" or otherwise hijacking a DLL from some other source? Just make once yourself. It's trivial to wrap the native common dialog functions provided by the Windows API into an ActiveX DLL using Visual Basic 6, which can then be called by your VBScript. The risks are minimal, since almost any modern version of Windows can be expected to already have the Visual Basic run-time installed, and since you presumably already know VBScript, banging out some code in VB 6 shouldn't be a very difficult undertaking. You can include whatever custom functionality that you want, and most importantly, you'll be in complete control. You won't have to worry about other application's uninstallers removing the DLL that your script requires, you won't have to futz with installing and uninstalling some random, deprecated application, and you won't have to just cross your fingers and hope. We know, as programmers, that's never a good option.
And yes, I recommend actually wrapping the common dialog functions exposed by the Windows API, rather than relying on the common dialog OCX (comdlg32.ocx) provided by Visual Basic. It has its share of problems in Windows 7, and it's not going to get you the gorgeous new dialogs that the later versions of Windows now provide. An excellent article explaining everything you need to know about the Open and Save Common Dialog APIs and how to use them in VB 6 is available here on VBnet. Of course, if you really want to go all out, there's loads of interesting stuff you can do with common dialogs, all documented (with code!) here on VB Accelerator.
But now that I have you all convinced to write an ActiveX DLL in VB 6 that wraps the common dialog functionality to use in your VBScript, I have to ask the question: Why stop there? Once you've made the leap to writing some code in VB 6, why not move all of your code into VB 6? Sure, it's a "dead" language and all, but it's not like VBScript is terribly active either. As I mentioned before, the difference in syntax is virtually nil, and the learning curve for a VBScript developer is about as shallow as one could expect. Plus, you get all of the benefits of a full IDE, static typing, (slightly) better error handling, blah blah blah. Oh yeah, and being able to make direct calls to the Windows API functions. The only real benefit to VBScript is its ubiquity, but it's been years since you could find a computer without the VB runtime installed. Not to mention, if you're writing an application that requires common dialog boxes, you're probably engaging in a dialog with your users: The forms capability of full VB might begin to come in handy at that point. But perhaps the biggest and most important advantage of choosing to go this route is that you eliminate any need to register (or include) an external "satellite" DLL—a simple VB 6 application will run with only the EXE on any computer that has the VB run-time installed, which is included at least up through Windows 7.
And finally, in case you're all sorts of excited about moving up from the lowly VBScript to the full-featured VB 6, I feel compelled to throw another wrench into the equation: Why not move all the way up to a language like VB.NET? Again, there are all sorts of new features offered in VB.NET thanks to the .NET Framework, but it shouldn't take more than a few weeks for a decent VB/VBScript developer to begin to feel comfortable writing apps in VB.NET. They probably won't have a full understanding of the .NET Framework, and they certainly won't have developed good object-oriented design practices, but at least they will be moving in the right direction. Almost anything that you can do in VBScript (or even VB 6), you can do in VB.NET. And generally, it requires even less fuss than before, thanks to the immense functionality exposed by the .NET Framework. The drawback, of course, is that your app now requires the .NET Framework be installed on the user's computer, which isn't quite as ubiquitous as the VB 6 run-time (although it's much more common now than even just a few years ago).
So I hear you saying those weren't the workarounds you were hoping to hear? Yeah, me neither. I'm not that guy who tells people to drop everything and learn a new language. If VBScript continues to work for you, go for it. But if you're at that point where you start to strain at its limitations, it's probably time to make the leap.
If you have some degree of control over the systems on which you'll be deploying this, and can be reasonably certain that they have either Visual Studio or Microsoft HTML Help installed, you can use code like the following:
function filedialog(filt, def, title, save)
set dialog = CreateObject("MSComDlg.CommonDialog")
dialog.MaxFileSize = 256
if filt = "" then
dialog.Filter = "All Files (*.*)|*.*"
else
dialog.Filter = filt
end if
dialog.FilterIndex = 1
dialog.DialogTitle = title
dialog.InitDir = CreateObject("WScript.Shell").SpecialFolders("MyDocuments")
dialog.FileName = ""
if save = true then
dialog.DefaultExt = def
dialog.Flags = &H800 + &H4
discard = dialog.ShowSave()
else
dialog.Flags = &H1000 + &H4 + &H800
discard = dialog.ShowOpen()
end if
filedialog = dialog.FileName
end function
Also, adapting one of the other answers to this question into VBScript code (thanks #oddacorn!), you should add this function if you aren't reasonably certain that your users will have VS or HTML Help. Call this function on program startup. Don't worry if you already have the key; in that case, this has no effect. This should work on a standard user account without admin rights.
'Make the MSComDlg.CommonDialog class available for use. Required for filedialog function.
function registerComDlg
Set objRegistry = GetObject("winmgmts:\\.\root\default:StdRegProv")
objRegistry.CreateKey &H80000001, "Software\CLASSES\Licenses\4D553650-6ABE-11cf-8ADB-00AA00C00905"
objRegistry.SetStringValue &H80000001, "Software\CLASSES\Licenses\4D553650-6ABE-11cf-8ADB-00AA00C00905", "", "gfjmrfkfifkmkfffrlmmgmhmnlulkmfmqkqj"
end function
Note that I adapted the filedialog function from the "View Source" of the VBScript code in the HTML here; on modern web browsers, it appears that the HTML they use to render the code samples doesn't display correctly (tested on IE 8 and Chrome). But fortunately the code is still there in the View Source.
I found one thing that was critical to making this work on Windows 7 (SP1, fully patched); you must set dialog.MaxFileSize = 256 or you will get a run-time error.
That is, the following code fails on Windows 7 SP1, but probably works on older versions of Windows:
Set x = CreateObject("MSComDlg.CommonDialog")
x.ShowSave
On
http://blogs.msdn.com/b/gstemp/archive/2004/02/18/75600.aspx
there is a way descibed how to show an Save As dialog from VBScript.
Note that according to
http://www.eggheadcafe.com/software/aspnet/29155097/safrcfiledlg-has-been-deprecated-by-microsoft.aspx
SAFRCFileDlg has been deprecated by Microsoft.
I just made a shell, linked it to a asp website, made the website read a directional tag - which i loaded the file location into, and the asp page opens up the file dialog immediate within that file location, with the filename also specificed through directional tags. Once saved, the shell disappears.
If it's a limitation of the website direcitonal tags ie (blah.com/temp.aspx?x=0&y=2&z=3)
store the information in a SQL db, or flat files, there are a ton of workarounds, but what above is said is true. VBS won't cut it internally.
After looking for ages, I've found jsShell - Shell Component at jsware.net. The zip file contains jsShell.dll 176 kB, a vbscript to register the dll basically regsvr32.exe jsShell.dll, demo scripts and clear documentation.
The DLL works well in Windows 7 and provides several useful methods, including the Open/Save dialog:
Dim jsS, sFileName
jsS = CreateObject("jsShell.Ops")
' Save as dialog
sFileName = jsS.SaveDlg("<title>", "exe") ' Example: Filter by exe files
sFileName = jsS.SaveDlg("<title>", "") ' Example: No extension filter
' Open dialog
' Example: Filter by exe, initial dir at C:\
sFileName = jsS.OpenDlg("<title>", "exe", "C:\")
When no file is selected, sFileName is an empty string.
Private Sub cmdB1_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles cmdB1.Click
Dim objExec, strMSHTA, wshShell, SelectFile
SelectFile = ""
' For use in HTAs as well as "plain" VBScript:
strMSHTA = "mshta.exe ""about:" & "<" & "input type=file id=FILE>" _
& "<" & "script>FILE.click();new ActiveXObject('Scripting.FileSystemObject')" _
& ".GetStandardStream(1).WriteLine(FILE.value);close();resizeTo(0,0);" & "<" & "/script>"""
wshShell = CreateObject("WScript.Shell")
objExec = wshShell.Exec(strMSHTA)
SelectFile = objExec.StdOut.ReadLine()
Me.txtT0.Text = SelectFile
objExec = Nothing
wshShell = Nothing
strMSHTA = Nothing
End Sub
I just found a solution in this site
It is fully commented and works well in Windows 10
Here is the code that returns the folder as a string (I tried in three different start folders):
Option Explicit
WScript.Echo BrowseFolder( "C:\Program Files", True )
WScript.Echo BrowseFolder( "My Computer", False )
WScript.Echo BrowseFolder( "", False )
Function BrowseFolder( myStartLocation, blnSimpleDialog )
' This function generates a Browse Folder dialog
' and returns the selected folder as a string.
'
' Arguments:
' myStartLocation [string] start folder for dialog, or "My Computer", or
' empty string to open in "Desktop\My Documents"
' blnSimpleDialog [boolean] if False, an additional text field will be
' displayed where the folder can be selected
' by typing the fully qualified path
'
' Returns: [string] the fully qualified path to the selected folder
'
' Based on the Hey Scripting Guys article
' "How Can I Show Users a Dialog Box That Only Lets Them Select Folders?"
' http://www.microsoft.com/technet/scriptcenter/resources/qanda/jun05/hey0617.mspx
'
' Function written by Rob van der Woude
' http://www.robvanderwoude.com
Const MY_COMPUTER = &H11&
Const WINDOW_HANDLE = 0 ' Must ALWAYS be 0
Dim numOptions, objFolder, objFolderItem
Dim objPath, objShell, strPath, strPrompt
' Set the options for the dialog window
strPrompt = "Select a folder:"
If blnSimpleDialog = True Then
numOptions = 0 ' Simple dialog
Else
numOptions = &H10& ' Additional text field to type folder path
End If
' Create a Windows Shell object
Set objShell = CreateObject( "Shell.Application" )
' If specified, convert "My Computer" to a valid
' path for the Windows Shell's BrowseFolder method
If UCase( myStartLocation ) = "MY COMPUTER" Then
Set objFolder = objShell.Namespace( MY_COMPUTER )
Set objFolderItem = objFolder.Self
strPath = objFolderItem.Path
Else
strPath = myStartLocation
End If
Set objFolder = objShell.BrowseForFolder( WINDOW_HANDLE, strPrompt, _
numOptions, strPath )
' Quit if no folder was selected
If objFolder Is Nothing Then
BrowseFolder = ""
Exit Function
End If
' Retrieve the path of the selected folder
Set objFolderItem = objFolder.Self
objPath = objFolderItem.Path
' Return the path of the selected folder
BrowseFolder = objPath
End Function
Set objDialog = CreateObject( "SAFRCFileDlg.FileSave" )
' Note: If no path is specified, the "current" directory will
' be the one remembered from the last "SAFRCFileDlg.FileOpen"
' or "SAFRCFileDlg.FileSave" dialog!
objDialog.FileName = "test_save.vbs"
' Note: The FileType property is cosmetic only, it doesn't
' automatically append the right file extension!
' So make sure you type the extension yourself!
objDialog.FileType = "VBScript Script"
If objDialog.OpenFileSaveDlg Then
WScript.Echo "objDialog.FileName = " & objDialog.FileName
End If
I have an application that has 'macro' capabilities. When I map some keys on the keyboard to perform the 'macro', I can also have it launch vbscript instead.
What i'd like to try and do is within my vbscript figure out what keys were used in order to launch the script. Is it posible to do this? Could there be a way in vbscript to figure out what keys were last touched on the keyboard and then I could apply my logic.
The purpose of doing this is to keep the code in a single .vb file instead of several seperate .vb script files(one for each keyboard mapping, possible 3-4). Obviously we are looking to just maintain 1 file instead of multiple files with essentially the same code in each one.
I am leaning towards the idea that this is not possible, but i figured this would be a worthy question for the masses of StackOverflow. Thanks for the help everyone!
What you are asking for is not possible.
Can you change your VBScript to accept parameters and then call it with a different parameter based on which hotkey was selected?
I agree with aphoria, the only way to make something like this possible is if your keyboard mapping software allows you to assign a script/command with parameters/arguments. For example if you used
c:\Temp\something.vbs
then you would change this to
%WINDIR%\system32\wscript.exe c:\temp\something.vbs "Ctrl-Alt-R"
Then in your vbscript code you could collect the argument using the wscript.Arguments object collection to do actions based on what argument/parameter was passed. See the following two links for more info:
http://msdn.microsoft.com/en-us/library/z2b05k8s(VS.85).aspx
http://www.microsoft.com/technet/scriptcenter/resources/qanda/sept04/hey0915.mspx
The one possible approach you may use is to install keylogger and read its log in your VBScript.
For example save script start time in the very beginning of the script
StartTime = Timer()
and then read one log record of your keylogger before this time.
Background
Lately I've become a fanatic that everything I type while working on a computer should be compatible with "DRY". If there's anything I have to type more than once in any context, I want some kind of user-aware auto-complete option to do some of the work for me -- always -- no exceptions.
Having to work under Windows, I've looked at GUI solutions to make this insane goal a reality.
The (almost) optimal solution
If you have a moment, open up Firefox 3.0 and type a few keystrokes into the address bar. You will notice that it performs a kind of Incremental Autocomplete based on space-separated sub-strings of whatever you type. Another place in Firefox that does something similar is the about:config URL.
This is sub-optimal, because I don't want this in Firefox only. I want to use this everywhere.
The Question
Does anyone out there know of a widget or app that does nothing but insanely good incremental auto-complete that can be used as a general purpose "run everywhere" tool? Something that allows the user to: 1) maintain one or more "completion candidate files"; 2) pick one of those files as the source for Firefox 3.0 style completion; 3) return the result (or blank if the user canceled), and do those three things only?
Details
Here's how it should work:
STEP1: user saves or more csv file(s) (or other easy-edit format) somewhere in his hard-drive
STEP2: user creates a Windows Script Host script or a batch file (or whatever) instantiates the FilterAsYouType GUI
STEP3: user runs the script file, and the script file instantiates the GUI, telling it which CSV file to use as the source of all potential completions
STEP4: the user either chooses one of the completions, supplies his own text that is not in the list, or cancels out without supplying anything
STEP5: when the user is done the script saves the result to a variable and does something with it
Here is some pseudo-code for the script:
include "GenericTypeaheadWidget";
var gengui = new GenericTypaheadWidget('c:\docs\favorite_foods.csv');
var fave_food = gengui.get_user_input();
if(fave_food != ''){
alert('you chose '+fave_food+'!');
}
The rationale
The goal is to just have a way to always be able to do auto-completions from a list of arbitrary items, even if the list is a couple thousand items, and not have to rely on it being built into some IDE or standalone application that only accepts certain kinds of input or has an overly-complicated API relative to the simplicity of this task.
CSV (or text or sqlite database) would provide a way for me to self-generate "candidate lists" or "history logs" and then just use those logs as the source of the possible completions.
The disclaimer
I've tried several GUI "launcher" programs, command-line engines like power-shell and scripting shells, the regular plain old command-line history with varying degrees of satisfaction. The problem with these is they all do extra superfluous stuff like searching directories or built-in commands. I just want nothing but whatever is in the CSV file I happen to be pointing at.
I'm wondering if there is any simple tool that does nothing but what I'm describing above.
UPDATE: It looks like this question is very closely related to Graphical Command Shell, which captures the essential idea presented here.
You should really try Launchy - it's exactly what you're looking for, a "run anything" with intelligent autocompletion. It completely changes the way you interact with a Windows PC.
And it has open source-code, so you can borrow its autocompletion code if you want to roll your own interface.