Windows 7 Scripting

[Schnozzinkobenstein]

Is it possible to write a script involving:
1) the menus you get when you right-click a folder
2) in dialog boxes prompting for textual input in Windows 7

If so, how?

To give you a good idea as to my technical experience, I have advanced experience with Java and C++, and knowledge in many other OOP and non-OOP languages, but I only dabbled in VBScript a tiny bit.

 

[Train]

Are you looking for the context menu (aka right click menu) or specific functionality WITHIN it?

i.e. Going through all the trouble to create and hook a context menu through code just to rename a folder would be overkill when you can just rename the folder in a single command.

 

[Nothinman]

The entries on the context menus in Explorer are just registry entries, it's trivial to add them without any bit of programming.

I believe VBScript can pop up dialog boxes for user input when invoked properly, however just looking at the language angers me so I can't say for sure right now.

 

[Schnozzinkobenstein]

Okay, since I wasn't very specific, three examples:

1) You have to rename 100 files in a way that can be define with an algorithm. For example, numbering the files or adding an X to ones that contain a keyword.

2) You need to access a context menu individually for 100 files, such as Right Click -> 7-zip -> Add to "filename.zip".

3) What I was referring to with the dialog boxes was something more like if you choose the "Add to archive..." option for a zipping utility, a window will come up with lots of drop down menus and text boxes. Can I work with them through VBScript?

I don't want to debate whether these things would ever be necessary. I just want to learn how to do them if it's possible. If there's a better way to do these things without using VBScript I'd also be interested in that.

 

[Train]

Some people would disagree with me, especially the system admin types who write vbScripts a lot. But personally I would write console apps in C# to do the types of things you are asking.

For example, we have a server here that stores images. It can store MILLIONS of them. Once a night we need to delete any image older than 90 days (or 60, or 45 days if the syadmin decides)

So I wrote a small console app that takes two params: a directory path, and a number of days back to look for. It loops through all the files int he directory, checks the date, and deletes any older then the specified # of days ago.

The advantage of using a console app is that it can be run via task manager when no one is logged in.

As for "add to archive", you dont need a context menu for that either. Various programming API's have this sort of functionality built in. IIRC .Net has built in zip functions that let you do just that.

 

[GeekDrew]

Some people would disagree with me, especially the system admin types who write vbScripts a lot. But personally I would write console apps in C# to do the types of things you are asking.

...

The advantage of using a console app is that it can be run via task manager when no one is logged in.

Yeah, I'm one of those sysadmins that sees no need for an application, when an interpreted script (of any language) will work just as well (and be more transparent).

What makes you think that scripts cannot be executed while logged off? I do it all the time.

 

[Nothinman]

Some people would disagree with me, especially the system admin types who write vbScripts a lot. But personally I would write console apps in C# to do the types of things you are asking.

For example, we have a server here that stores images. It can store MILLIONS of them. Once a night we need to delete any image older than 90 days (or 60, or 45 days if the syadmin decides)

So I wrote a small console app that takes two params: a directory path, and a number of days back to look for. It loops through all the files int he directory, checks the date, and deletes any older then the specified # of days ago.

The advantage of using a console app is that it can be run via task manager when no one is logged in.

As for "add to archive", you dont need a context menu for that either. Various programming API's have this sort of functionality built in. IIRC .Net has built in zip functions that let you do just that.

And we would disagree because your "advantage" doesn't exist. Advantages like being able to edit the script later without having to recompile the whole thing do exist and outweigh pretty much any advantages a compiled app would have over a script for something like this.

 

[Train]

And we would disagree because your "advantage" doesn't exist. Advantages like being able to edit the script later without having to recompile the whole thing do exist and outweigh pretty much any advantages a compiled app would have over a script for something like this.

Having to recompile it only becomes a disadvantage when you hard code all your params. XML, app.config, or a .txt is easily editable in any text editor. Often I just use one of those.

Advantages being, I wrote vbScript for years, then switched to C# and can do 100x as much in the same amount of time. It's just way more powerful.

Not being able to recompile is a consistency advantage. If I give IT a plain text script, they will edit it, and eventually have a bunch of variants all over the network. It's inevitable, they will tweak one for a specific server's settings, then copy it somewhere else, and cause problems. If I give them an EXE, so that they can only edit the config file or command line params, it removes a maintenance and troubleshooting headache.

 

[Nothinman]

Having to recompile it only becomes a disadvantage when you hard code all your params. XML, app.config, or a .txt is easily editable in any text editor. Often I just use one of those.

Or the functionality of the script needs changed a bit or if you find a bug, etc. It's a disadvantage regardless of the reason for the change.

Not being able to recompile is a consistency advantage. If I give IT a plain text script, they will edit it, and eventually have a bunch of variants all over the network. It's inevitable, they will tweak one for a specific server's settings, then copy it somewhere else, and cause problems. If I give them an EXE, so that they can only edit the config file or command line params, it removes a maintenance and troubleshooting headache.

At my last job we used virtually all perl for our server scripting jobs. While we did use perl2exe for DMZ hosts that we didn't want to install ActiveState Perl, the rest of the Windows servers had perl on them and the source for all of the scripts was kept in a central place where everyone knew the location. No one ran around editing scripts willy-nilly because they knew better. If they needed a change made they went through the proper channels and had it done in the main script and deployed everywhere.

That's a procedural problem, not technical one. Just because you can't trust your IT people doesn't mean that's the same everywhere. Not requiring Visual Studio to recompile it, not requiring the .Net framework and having the source right there are all advantages from my perspective.

 

[Train]

Like I said, it's a matter of preference. But when I switched from vbs to C# I kicked myself for not doing it years sooner.

And technically, you don't need visual studio to compile C#, the .net framework can compile it on its own. If you REALLY wanted a raw source file, it can be set up to compile on the fly.

Paint.Net has a plugin that lets you type an effect (in C#) into a text window, and it compiles it as you type, applying to effect to the image. It's a pretty badass example of in-memory compilation in .Net. Show me a vbs that can compile and chew through a multi megapixel image in a tenth of second.

 

[Nothinman]

Like I said, it's a matter of preference. But when I switched from vbs to C# I kicked myself for not doing it years sooner.

I personally hate VBScript and JScript, but they're the only two languages that Windows supports out of the box. If you're going to install something extra on all of your servers you might as well go the Perl or Python route at that point.

And technically, you don't need visual studio to compile C#, the .net framework can compile it on its own. If you REALLY wanted a raw source file, it can be set up to compile on the fly.

Paint.Net has a plugin that lets you type an effect (in C#) into a text window, and it compiles it as you type, applying to effect to the image. It's a pretty badass example of in-memory compilation in .Net. Show me a vbs that can compile and chew through a multi megapixel image in a tenth of second.

Nice strawman. Making you compile the code isn't an advantage even if it's only in memory and the OP was talking about sysadmin-like operations, not image editing. And speed of the interpreter was never in question, I wouldn't be surprised if the windows scripting host was abysmally slow. But in reality it doesn't matter because it's never used for performance critical jobs.

 

[Train]

I personally hate VBScript and JScript, but they're the only two languages that Windows supports out of the box. If you're going to install something extra on all of your servers you might as well go the Perl or Python route at that point.

Well the Topic Title does say "Windows 7", which DOES support .Net 3.5 SP1, "out of the box"

 

[Train]

blah...Making you compile the code isn't an advantage even if it's only in memory ... blah

I never said it was, but it removes the disadvantage you claimed it had.

 

[Markbnj]

That's a procedural problem, not technical one. Just because you can't trust your IT people doesn't mean that's the same everywhere. Not requiring Visual Studio to recompile it, not requiring the .Net framework and having the source right there are all advantages from my perspective.

CruiseControl.net provides the build management for our team, and it's pretty trivial to pick an svn branch and push it to whatever server we want. And you always need some framework, whether it's the java runtime or the boost libs.

But anyway, it's sort of a meaningless argument. They're both programming languages, and either is capable of doing what you want. I'd say use the easiest, most accessible language up to the point where you need the capabilities of another, and in all cases put your scripts/source under scm and build management.

 

[Sureshot324]

The tasks you describe can all be done by command line scripts, but for things that can't, there's AutoIt, http://www.autoitscript.com/autoit3/index.shtml, which is a Windows GUI scripting program. Basically it can automate any sequence of GUI events, such as clicking on menus/buttons etc..

I used this for switching between different sound devices. On Windows XP this is just a registry value so it can easily be scripted with a bat file, but on Windows 7/Vista there's no known way to do this. I have a 2 sound cards (pci+onboard) and my onboard has a front and rear jack. My good headphones are plugged into the pci card, my headset is plugged into the front jack, and my speakers are plugged into the rear jack (onboard). I have AutoIt scripts set so I can easily switch to any one of them with a single click on the taskbar. It actually opens the sound control panel and clicks the buttons.