I need to write some vbscripts in my new project. I was told by other people that vbscripting is easy, but seems to me, it is not. For example, in the following example (provided by microsoft), these functions: CreateObject, CreateShortcut, as well as these property names: TargetPath, WindowStyle, Hotkey, etc, are used, but I just cannot find the corresponding API documentation about how to use them. In other words, how do you know you need to call these functions in your vbscripts? Visual Studio 2008/2010 do not have templates for vbscript either. Could anybody tell me what I am missing, and what the best way is to do vbscripting?
set WshShell = WScript.CreateObject("WScript.Shell")
strDesktop = WshShell.SpecialFolders("Desktop")
set oShellLink = WshShell.CreateShortcut(strDesktop _
& "\MyExcel.lnk")
oShellLink.TargetPath = _
"C:\Program Files\Microsoft Office\OFFICE11\EXCEL.EXE"
oShellLink.WindowStyle = 1
oShellLink.Hotkey = "CTRL+SHIFT+F"
oShellLink.IconLocation = _
"C:\Program Files\Microsoft Office\OFFICE11\EXCEL.EXE, 0"
oShellLink.Description = "My Excel Shortcut"
oShellLink.WorkingDirectory = strDesktop
oShellLink.Save
Take a look here (MSDN).
The objects you are working with are documented there (of course, it's MSDN documentation so it's not ideal, but it's documented nevertheless).
Specifically the WshShortcut Object and the WshShell etc.
I don't think VBScript is a very easy language, especially if you need to write larger scripts.
If you don't specifically need to write a script but it would be ok with an executable I'd look at using VB.Net instead, where you have a good development environment that makes everything much easier since you have Intellisense and you can just press F1 for the documentation. And since it's a typed language with a large framework it gets easier to avoid mistakes and many operations you need you can just call a method in the framework rather than writing your own code.
However, if you do need to do it in VBScript, I'd suggest trying to find some kind of IDE for it. I haven't used any, but at least this one seems worth looking at.
The language of VBScript is relatively easy. It's a subset of Visual Basic and VBA and simplifies some things from those environments (eg you don't need to declare variable types).
What you are dealing with above is working with the methods and properties of a given object, WshShell. There are many many objects out there, each with their own set of methods and properties to know about, many with common usage conventions, and many more with "unique" (ie idiosyncratic) usage requirements. This is where the complexity comes in, but it's not part of VBScript itself. You will run into this with any other language (JScript, Python, Delphi) that works with the myriad objects and APIs that are out there for Windows system management.
The plus side is that once you get used to the language of VBScript and the process of looking up object API references and examples on MSDN and other sites, it does become very easy to put together complicated and powerful scripts.
Like I frequently tell users, computers often make things faster the second time you do something. The first time usually requires some learning.
A great set of resources for learning VBScript and how you need to approach things is the
TechNet Script Center, their Hey, Scripting Guy! series, and the Script Repository.
Related
I have been searching for a FAQ to tell me how to open a Excel Workbook/Worksheet and also how to Save the File once I have finished.
I notice that in most FAQ and all the books I have purchased on F# one is show how to create a new Workbook/Worksheet but is never shown how to either open or Save it.
Being a newbie to F# I would very much appreciate it if anyone could kindly provide me with either an answer or perhaps a few pointers?
Update
As for why F# and not C# or VB?
I am pleased to say that inspite of being a newbie (with the exception of Forth, VBA & Excel 2003, 2007 & 2010 and Visual Basic) I can do this in both VB, VBA & C# and since I've been retired on medical grounds, with plenty of time unfortunately on my hands, I like to continually set myself challenges to keep my little grey cells active and being a sucker for trying new languages....well!
F# is now an intergral part of Visual Studio 2010 so I thought - why not. Consider this - if we are not willing to use or at least try a new languages - I would always be wonder if I might have prefer it to VBA, VB, C# ..... and if you look at it from another point of view, if no one is going to use it - why create it in the first place? I suppose you can say if cave men hadn't experimented and made fire by rubbing two sticks together - where would we be now and would matches have been invented?
Although an complete answer would be good, I prefer a few pointers, to keep my challenge going.
And lastly but not least - thank you for taking the trouble to respond!
I don't think their is a specific F# library for Office, so you will just use the exact same .NET library that you use in VB.NET/C#. F# is a .NET language, so anything that can be done in C# can be done in F# (but you probably already knew that :) ). The API call will be exactly the same, it just that they will be done using the F# syntax instead of the VB/C# one. So for example something that look like this
public void SaveMyWorkbook() {
string filePath = #"C:\failworkbooks\catfail.xlsx";
workbook.Save(filepath);
}
Will be expressed in F# as
let filePath = "C:\\failworkbooks\\catfail.xlsx";
let saveWorkbook() = workbook.Save(filePath) |> ignore //if the Save method return something
Now, what you will soon realize is that the API isn't exactly designed to be easily used from a functional language. It can be done, but this task in particuliar is much more tailored to C#/VB.NET.
If you really want to enjoy F#, I suggest you use in area where its strength really show. My personal experience is that functional language are awesome when a lot of math is involved. It is also marvellous if you want to easily introduce parallelism in your application (since F# code is usually side effect free). So anything that require data crunching on a lot of data is perfect for it. But for task that consist mainly of putting together a bunch of API call to an external library, F# is kind of meh. You could say that F# is kind of like a graphic card programming language, while C# a general purpose CPU programming language. A lot of thing run better with C#, but the stuff that run better on F# run really better on it.
But if you really want to go that route, my suggestion is to try to use the Office API as you already know it, but with a F# syntax. If at some point you really have no idea how to do a specific task, ask a question about it on stackoverflow with your code and exactly want you want to do. Those question get answered ridiculously fast compared to broad all-encompassing question, so you won't wait long. (Programmer seem to love precise question with a specific answer ^^)
I hope that it helped a little.
I found this http://iouri-khramtsov.blogspot.co.uk/2011/12/automating-excel-with-f.html helpful advice. Briefly, you'd use something like this:
#r "Microsoft.Office.Interop.Excel" // Assuming it's a script
let excel = ApplicationClass(Visible = true)
let openFileName = #"C:\MyDir\MyFilenameToOpen.xls"
excel.Workbooks.Open(openFileName)
// Do stuff
let savedFileName = #"C:\MyDir\MyFilename.xls"
workbook.SaveAs(savedFileName)
Using F# with Excel seems like a natural fit.
Getting to a result in Excel requires the use of several immutable values, each driven by formulas. Excel has a brilliant user interface, a lovely model of the world - I love rows, columns and cells - but to automate or customise things requires macros. Why learn this when you can use F#? Formulas and immutable values are fundamental to its design.
Ideally you'd write formulas yourself as a User Defined Function (UDFs) also in F# - see http://excel-dna.net/ . Then, perhaps, you'd want to do something interesting with objects/types - Look for "github com mndrake ExcelObjectHandler" (I don't have enough reputation to post a 3rd link).
Jack
I have a vb6 app that uses Word interop to create a few reports. In the introduction of these reports, there are some instructions in 4 textboxes around an image.
Recently and suddenly the top two textboxes started appearing on the next page, and I can't figure out why. When I step through the code and watch the word document getting built, everything positions itself correctly, however, if I compile the application, the error reappears.
Any suggestions?
Use late-bound calls to Word. This does not mean to remove reference to Microsoft Word Xxx Object Library, just alter your Dims like this
Dim oWord As Object '--- was Word.Application'
Dim oDoc As Object '--- was Word.Document'
...
oDoc.Protect wdAllowOnlyReading '--- keep using enums'
Could it be some 'rounding' difference? For instance if you compare two float point values for equality, the result can subtly depend on the specific compiler/interpreter implementation.
I would like to suggest to trim down your code to the minimum showing the different behaviors. That might clear things up already. If not, please post it here to let us help you.
Maybe you are running the compiled version as a different user than the one running VB when you debug? Maybe this could cause what you are describing, if the two users have some different Word settings.
Is it possible that the compiled version finds a different version of the .dot file?
It may be very helpful if you show the code you use to create the Word document, because then someone here might notice something that can be sensible to moving to a compiled version.
Do you have any code in events that rely on timing, such as Form_Activate, Load, or Unload? I've seen those things behave very differently when stepping through code and when compiled, especially on newer, faster machines.
I need to write some scripts for WinXP to support some of the analysts here at Big Financial Corp. I need to decide which type of Windows scripting best fits my needs.
My needs seem pretty simple (to me anyway)
run on WinXP Pro SP2 (version 2002)
not require my users to install anything (so PowerShell is out. Likewise Perl, Python, and other common suggestions for these types of questions on Stack Overflow)
written in a non-compiled language (so users have a chance to modify them in the future)
reasonably complete language features (especially date/time manipulation functions. I would like to also have modern concepts like subroutines, recursion, etc)
ability to launch and control other programs (at the command line)
From my hurried review of my options, it looks like my choices are
VBScript
WScript
JScript
I don't have time to learn or do an in-depth review of these (or whatever else a standard install of WinXP has available). I need to pick on and hack something together as quickly as possible.
(Current crisis is the need to run a given application, passing several date parameters).
Once the current crisis is over, there will be more requests like this.
Edit
My current skill set includes Perl, JavaScript, and Java so I'm most comfortable using something similar to these
Edit
OK. I'll try writing a WSH file in JScript. I'll let you know how it goes (and figure out accepting an answer) once things settle down around here a bit.
Edit
It all worked out in the end. Thanks for the quick responses folks. Here's what I gave my user:
<job id="main">
<script language="JScript">
// ----- Do not change anything above this line ----- //
var template = "c:\\path\\to\\program -##PARAM## --start ##date1## --end ##date2## --output F:\\path\\to\\whereever\\ouput_file_##date1##.mdb";
// Handle dates
// first, figure out what they should be
dt = new Date();
var date1 = stringFromDate(dt, 1);
var date2 = stringFromDate(dt, 2);
// then insert them into the template
template = template.replace(new RegExp("##date1##", "g"), date1);
template = template.replace(new RegExp("##date2##", "g"), date2);
// This application needs to run twice, the only difference is a single parameter
var params = ["r", "i"]; // here are the params.
// set up a shell object to run the command for us
var shellObj = new ActiveXObject("WScript.Shell");
// now run the program once for each of the above parameters
for ( var index in params )
{
var runString = template; // set up the string we'll pass to the wondows console
runString = runString.replace(new RegExp("##PARAM##", "g"), params[index]); // replace the parameter
WScript.Echo(runString);
var execObj = shellObj.Exec( runString );
while( execObj.Status == 0 )
{
WScript.Sleep(1000); //time in milliseconds
}
WScript.Echo("Finished with status: " + execObj.Status + "\n");
}
// ----- supporting functions ----- //
// Given a date, return a string of that date in the format yyyy-m-d
// If given an offset, it first adjusts the date by that number of days
function stringFromDate(dateObj, offsetDays){
if (typeof(offsetDays) == "undefined"){
offsetDays = 0;
}
dateObj.setDate( dateObj.getDate() + offsetDays );
var s = dateObj.getYear() + "-"; //Year
s += (dateObj.getMonth() + 1) + "-"; //Month (zero-based)
s += dateObj.getDate(); //Day
return(s);
}
// ----- Do not change anything below this line ----- //
</script>
</job>
Clearly it could be better... but it got the job done and is easy enough for my user to understand and extend himself.
These are all technically the same thing with different syntax. Actually WScript/CScript is the engine, VBScript and JScript are the languages.
Personal opinion only follows: My personal recommendation is JScript because it reminds me more of a real programming language, and makes me want to punch myself in the face less often than VBScript. And given your familiarity with javascript, your best bet is JScript.
Going into a bit more detail about the difference between WScript and CScript as others have: these are your execution platforms for your scripts for the Windows Script Host. They are essentially the same thing, whereas WScript is more GUI oriented, and CScript is more console oriented. If you start the script with CScript, you will see a console window, but you still have access to GUI functionality, whereas if you start with WScript, there is no console window, and many of the default output methods display as windowed objects rather than a line in the console.
If you like JavaScript, you'll probably be ok with JScript. It's a decent language, and certainly more suitable for complex scripts than VBScript.
However, Microsoft1 hates JavaScript, so you'll encounter some APIs that are trivial to use with VBScript but painful to access using JScript. Consider yourself warned...
As snicker notes, WScript is the engine that drives both.
1 Anthropomorphization used to note general lack-luster support; not to be interpreted as evidence of any official policy.
Although JScript is a much less horrible language than VB Script, the problem is that VB Script has a more complete library of helpful functions built into it for things like date and number formatting. So it's not actually as easy a choice as it first appears, unless you are able to write and install your own library of helper objects to use with JScript.
Some details here.
Don't forget CScript. And be careful here, because the windows scripting host is often disabled by group policy at large companies. If that's the case, the only option that fits all your criteria is (shudder) batch.
If none of those work out for you, your best option is probably a compiled program where you distribute the source with the program.
Use JScript. A key difference between using JScript with the WScript/cscript engine and writing JavaScript in the browser is that you don't have the browser security restrictions. You also have access to ActiveX/COM objects for manipulating applications, the registry, etc. In fact, you'll probably spend a lot more time reading up on those custom objects and interfaces than worrying about the language features. Of course, you get all the benefits of JavaScript dates, regex's, etc.
A sample JScript app from MSDN might help to get you started.
Unfortunately, most of Microsoft's sample scripts tend to be VBScript, but the syntax is pretty easy to follow, especially if you're just trying to pick out COM interface details.
To expand on the other's answers a bit, WScript and CScript are programs used to run scripts written in VBScript (Visual Basic like syntax) or JScript (JavaScript-like syntax). CScript runs scripts from a console window, so that the Echo command writes to the console, whereas WScript runs them without a window and the Echo command writes to a popup message box.
You can write WSH (Windows Scripting Host) and WSC (Windows Scripting Component) scripts that use both VBScript and JScript by combining them in an XML-based wrapper, if you need to merge pre-existing code in the two languages.
You can also write HTA scripts, which stands for "HyperText Application". These are script code in an HTML file with the HTA extension that runs in Internet Explorer, which allows you to provide an interface using HTML controls, but also have complete access to your system because the run locally.
All of these are based on the Windows Scripting Host and Active Scripting technologies which have been included with all Windows computers since Windows 98. Along with fairly powerful base languages, they also give you access to WMI for extensive system and network information and management, and COM capability for automating Word, Excel etc. Also you can use ADO and ADOX to create and work with Access MDB files even if Access is not installed.
My choice would be WSH using JScript. You could use VBScript, but why, when JScript is available.
Here is a reference for Windows Script Host.
Very simple question that is apparently impossible to find a decent answer to: How can I make Visual Basic 6 stop changing my ^##*ing variable casing!?!
I know that the general opinion of a great many VB users is that this "feature" is actually quite helpful, but I doubt that they use it much with any source control system. This is absolutely INFURIATING when you are trying to collaborate on a project of any significant size with several other developers. If ignored, you produce thousands of false-positive "changes" to your files (even ones with no actual code changes!) that pollute the revision history and make it near impossible in some cases to locate the actual change that took place.
If you don't ignore it (like my office, where we have been forced to implement a "no unneeded case change" policy), you spend 5x the time you would normally on each commit because you have to carefully revert out VB's "corrections" on every file, sometimes reverting hundreds of lines to put in a one line change.
Surely there must be a setting, plugin, hack, etc. out there that can remove this unwanted "feature"? I am willing to take any method I can get as long as it doesn't require me to pick through piles of phantom diffs. And to squash a couple of complaints up front: No, I can't turn off case detection in my diff tool, that's not the point. No, we can't just make the case changes globally. We're working with hundreds of thousands of LOC being worked on by multiple developers spanning many years of development. Synchronizing that is not feasible from a business standpoint. And, finally: No, we cannot upgrade to VB.net or port to another language (as much as I would love to).
(And yes, I am just a tiny bit peeved at the moment. Can you tell? My apologies, but this is costing me time and my company money, and I don't find that acceptable.)
Depending on your situation adding
#If False Then
Dim CorrectCase
#End If
might help.
Here is a real world scenario and how we solved it for our 350k LOC VB6 project.
We are using Janus Grid and at some point all the code lines which referenced DefaultValue property of JSColumn turned to defaultValue. This was an opportunity to debug the whole IDE nuisance.
What I found was that a reference to MSXML has just been added and now the IDE picks up ISchemaAttributes' defaultValue property before the Janus Grid typelib.
After some experiments I found out that the IDE collects "registered" identifiers in the following order:
Referenced Libraries/Projects from Project->References in the order they are listed
Controls from Project->Components (in unknown order)
Source Code
So the simple fix we did was to create a dummy class/interface with methods that hold our proper casing. Since we already had a project-wide typelib we referenced from every project before anything other typelib, this was painless to do.
Here is part of the IDL for our IUcsVbIntellisenseFix interface:
[
odl,
uuid(<<guid_here>>),
version(1.0),
dual,
nonextensible,
oleautomation
]
interface IUcsVbIntellisenseFix : IDispatch {
[id(1)] HRESULT DefaultValue();
[id(2)] HRESULT Selector();
[id(3)] HRESULT Standalone();
...
}
We added a lot of methods to IUcsVbIntellisenseFix, some of them named after enum items we used to misspell and whatever we wanted to fix. The same can be done with a simple VB class in a common library (ActiveX DLL) that's referenced from every project.
This way our source code at some point converged to proper casing because upon check-out the IDE actually fixed the casing as per IUcsVbIntellisenseFix casing. Now we can't misspell enums, methods or properties even if we try to.
SIMPLE WAY: Dim each variable in the case that you want. Otherwise, VBA will change it in a way that is not understandable.
Dim x, X1, X2, y, Yy as variant
in a subroutine will change ALL cases to those in the Dim statement
I can sympathise. Luckily we're allowed to turn off case sensitivity in our version control diff tool!
It seems the VB6 IDE automatic case-correction occasionally changes case in variable declarations and references, perhaps depending on the order in which modules are listed in the VBP file? But the IDE doesn't tell you that the file needs to be saved. So the problem only shows up when you saved the file because of another edit. We briefly tried to prevent this by checking out all the files in a project and setting the case carefully, but it didn't go away.
I suppose you could list the variable names that are affected - the usual suspects are one letter names like "I", "X" and "Y", perhaps because they are used in standard event handlers like MouseDown. Then write an add-in that'll search for all declarations " As" and force the case to upper. Run the add-in on your modules before you check them in. You might be able to trigger the add-in to run automatically when you save in VB6.
EDIT: Something I've just thought of: adapt Fred's answer. From now on, every time you check in a file, add a block at the top to establish canonical case for the usual suspects. If nothing else, it's easier than reverting hundreds of lines by hand. Eventually you will have this block in every file & maybe then the problem will stop happening.
#If False Then
Dim I, X, Y ' etc '
#End If
I standardised the case across the codebase, normally by using the examples above (Dim CorrectCase), and removing it again.
I then triggered VB to save EVERY file, by doing a case sensitive search/replace of "End" with "End" (no functional change, but enough to get VB to resave).
Once that was done, I could then do a single commit to standardise the case, making it MUCH easier to keep on top of it at a later date.
In this example VB6 was changing the case of the following line following a typo I made when referencing a library: -
Dim MyRecordset As ADODB.REcordset
Ugly, and now every other instance of an ADODB.REcordset thus acquired the new misspelling. I fixed this as follows: -
Type in a new declaration as follows
Dim VB6CasingSucks AS ADODB, Recordset
Note the comma and space after ADODB. Hit [ENTER] for VB6 to check the line.
At this point all instances of REcordset change back to Recordset.
Delete your new declaration.
I don't know if this fix will help with enums/other variable names.
Specifically for controlling the case of enum values, there is a VB6 IDE add-in which may be helpful. Enums seem to have a slightly unique version of this problem.
As described in the link below:
The VB6 IDE has an annoying quirk when it comes to the case of Enum
members. Unlike with other identifiers, the IDE doesn't enforce the
case of an Enum member as it was declared in the Enum block. That
occasionally causes an Enum member that was manually written to lose
its original case, unless a coder typed it carefully enough.
...
However, if a project contains a lot of Enums and/or a particular Enum
has a lot of members, redeclaring the members in each of them can get
quite tedious fast. ...
Ref: http://www.vbforums.com/showthread.php?778109-VB6-modLockEnumCase-bas-Enforce-Case-of-Enums
...load and unload the add-in as needed via the Add-In Manager
dialog box. Usage is as simple as selecting the entire Enum block,
right-clicking and then choosing the "Lock Enum Case" context menu
item.
I have a similar problem:
in a bas module there I wrote :
Private sub bla_bla()
Dim K as integer
End Sub
so in a class module the Dim k as integer will automatically be replaced by IDE become 'Dim K as integer' <-- it's not logical but then:
I correct the bas module become:
Private sub bla_bla()
Dim k as integer
End Sub
then magically the problem in the class module was solved (still be k and not automatically replaced by IDE become K). Sorry I'm poor in English
I don't think there's any to do it. The IDE will change the case of the variable name to whatever it is when it's declared. But, honestly, back in the day I worked on several large VB6 projects and never found this to be a problem. Why are people on your development team constantly changing variable declarations? It seems like you have not established a clear variable naming policy that you enforce. I know your upset, so no offense, but it might be your policies that are lacking in this regard.
Unfortunately, according to this SO thread, alternate VB6 IDEs are hard to come by. So, your best bet is to solve this problem via policy. Or move to VB.NET. :)
Wow. I've spent a lot of time programming in VB6 and I have no idea what you're on about. The only thing I can think you're referring to is that intellisense will change the capitalization of variable names to match their declarations. If you're complaining about that, I would have to wonder why the hell they've been entered any other way to begin with. And if that is your problem, no, there's no way to disable it that I'm aware of. I'd suggest you, in one go, check out every file, make sure the caps on the declarations and uses of variables all match and check back in.
I have a VS project with an IntermediateDirectory like this: "....\temp\$(SolutionName)\$(ProjectName)".
I can read this value using a macro or add in, however, I would need the actual directory to manipulate files there. Right now, I manually replace the "$(SolutionName)" and "$(ProjectName)" with the respective values, which works fine but might become complicated when different macros or even user macros from property sheets are used.
So my question is:
Does the Visual Studio API have a built in function to expand macros like these? Or is there some other elegant solution?
There is an elegant solution! But I only know the one that applies to C++ projects.
Assuming you're in a C# add-in:
// Get the main project from the first startup project
VCProject vcMainProject = (VCProject)(_applicationObject.Solution.SolutionBuild.StartupProjects as IVCCollection).Item(1);
Project mainProj = (Project)_vcMainProject .Object;
// Get the configuration we'll be using
IVCCollection cfgs = (IVCCollection)_vcMainProject .Configurations;
VCConfiguration vcCfg = (VCConfiguration) cfgs.Item(mainProj.ConfigurationManager.ActiveConfiguration.ConfigurationName + "|" + mainProj.ConfigurationManager.ActiveConfiguration.PlatformName);
string finalString = vcCfg.Evaluate("....\temp\$(SolutionName)\$(ProjectName)");
You can also check out this page:
http://msdn.microsoft.com/en-us/library/czt44k0x%28VS.71%29.aspx
If you're not using this for C++, there should be a similar interface for the Project, Configuration, and Solution classes provided for other languages (C# and VB).
As far as i know, there is no API available that will expand those macro values. Although it shouldn't be too hard to write a quick and dirty implementation that deals with only the values that you care about.
For instance, in this case you only care about 2 values (SolutionName and ProjectName). If these are the values you are primarily interested in use a simple search and replace with the best values.
Yes this is a sub-optimal solution. But it may help to unblock your progress.