How to make Computer System More User Friendly?

[Praxey]

Hello Friends,

I have decided to made this thread to all those who are Newbie and want to make the Computer System more User Friendly.
I had also face the same problem when I was New to the Computer World, so I am thinking that, New user should not face the same problem.

I am posting each Tips and Tweaks in each of my reply.

How Can Tell Whether the NumLock Key is On or Off

How Can I Password-Protect an Excel Spreadsheet?

How Can I Change the Target of a Desktop Shortcut?

How Can I Delete All Files Older Than a Specified Date?

How Can I Change the Target of a Desktop Shortcut?

[Praxey]

Hello Friends,

I have decided to made this thread to all those who are Newbie and want to make the Computer System more User Friendly.
I had also face the same problem when I was New to the Computer World, so I am thinking that, New user should not face the same problem.

I am posting each Tips and Tweaks in each of my reply.

How Can Tell Whether the NumLock Key is On or Off?

1.you can’t use a technology like WMI, Windows Script Host, or the Shell object to determine whether or not the NumLock key is on. And yet, you can use Microsoft Word to carry out that task:

Set objWord = CreateObject("Word.Application")
Wscript.Echo "NumLock key is on: " & objWord.NumLock
objWord.Quit

Granted, it’s a little weird; on the bright side, it’s also a very simple little script. To begin with, we create an instance of the Word.Application object. Notice, however, that – unlike most of our Microsoft Office scripts – we don’t set the Visible property to True; that’s because there’s no reason to make Word visible. That’s due, at least in part, to the fact we need Word for only one thing: to check the value of the NumLock property. To determine whether or not the NumLock key is on we only have to execute this line of code:

Wscript.Echo "Numlock key is on: " & objWord.NumLock

After that we simply call the Quit method and terminate our instance of Word.

Weird, but effective.

Incidentally, you can also use this same basic approach to determine whether or not the CapsLock key is on; the only difference is that you echo back the value of the CapsLock property:

Set objWord = CreateObject("Word.Application")
Wscript.Echo "CapsLock key is on: " & objWord.CapsLock
objWord.Quit

Now, admittedly, you probably don’t really need a script to tell whether the NumLock key (or even the CapsLock key) on your local computer is on or off; a quick glance at the keyboard will probably suffice. But that’s OK: this script can also be used to determine whether the NumLock (or CapsLock) key on a remote computer is on or off. All you have to do is pass the name of the remote computer as the second parameter to the CreateObject method. For example, this script determines the status of the NumLock key on the remote computer atl-fs-01:

Set objWord = CreateObject("Word.Application", "atl-fs-01")
Wscript.Echo "NumLock key is on: " & objWord.NumLock
objWord.Quit

The one thing that this script can’t do is change the status of the NumLock key: it can tell you that the NumLock key is on but it can’t turn it off for you. (That’s because the NumLock property is read-only.) About the only way we know to toggle the NumLock key on and off is to use the SendKeys method:

Set objShell = CreateObject("WScript.Shell")
objShell.SendKeys "{NUMLOCK}"

This works, although it won’t work on remote computers (SendKeys works on only the local machine). However, this might be useful in a logon script: in such a script you could check the status of the NumLock key and then, if needed, turn it on or off.

[Praxey]

Here I will provide you some tips regarding how to make excel sheet password protected.

Any time you call the SaveAs method you can include password-protection as an optional parameter. To demonstrate, here’s a script that creates a new worksheet, writes the current date and time in cell A1, and then saves the worksheet as C:\Scripts\Test.xls. On top of that, it password-protects the spreadsheet, giving it the password %reTG54w:

Set objExcel = CreateObject("Excel.Application")
objExcel.Visible = True
objExcel.DisplayAlerts = FALSE

Set objWorkbook = objExcel.Workbooks.Add
Set objWorksheet = objWorkbook.Worksheets(1)

objWorksheet.Cells(1, 1).Value = Now
objWorkbook.SaveAs "C:\Scripts\Test.xls",,"%reTG54w"
objExcel.Quit

If you’ve done any scripting with Microsoft Excel, this is about as simple a script as you’ll ever write. The only “gotcha” to be aware of occurs in this line of code, where you actually save the file and password-protect it:

objWorkbook.SaveAs "C:\Scripts\Test.xls",,"%reTG54w"

Admittedly, there’s nothing fancy about this line of code; you just have to make sure the password (%reTG54w) is the third parameter passed to the SaveAs method. The first parameter is, of course, the file name. The second parameter is the file format. Because we’re using the default format, we don’t need to set a value for the second parameter; however, we do need to include a placeholder for that parameter. That’s what the back-to-back commas (,,) are for: they simply indicate that the value for the second parameter would go here if we actually had a value for the second parameter. By including this placeholder, the password becomes the third parameter, which is exactly what we want.

After you run this script, try to open the file C:\Scripts\Test.xls; you’ll be prompted to enter the password before the file will actually be opened. Incidentally, this will happen even if you try opening the file using a script. (Sorry, but using a script won’t allow you to bypass the password protection.) But can’t you specify the password when you open the file? Of course you can; that’s what happens with this script:

Set objExcel = CreateObject("Excel.Application")
objExcel.Visible = True
objExcel.DisplayAlerts = FALSE

Set objWorkbook = objExcel.Workbooks.Open("C:\Scripts\Test.xls",,,,"%reTG54w")

Note that when opening a spreadsheet the password has to be the fifth parameter; thus we have the file name, three placeholders, and then the password. This can be a little confusing, to say the least, but here’s a rule of thumb: just put in one more comma than you have placeholders. In this example, we have three placeholders, so we insert four commas. If we had nine placeholders, we’d insert ten commas. And so on.

But what if you decide later on to remove the password? No problem: simply open the file and set the value of the Password property to an empty string. Here’s a script that does just that: it opens the spreadsheet, removes the password, and then uses the SaveAs method to re-save the file. After running this script, try to open this spreadsheet from within Windows Explorer; you should be able to do so without being prompted for a password.

Set objExcel = CreateObject("Excel.Application")
objExcel.Visible = True
objExcel.DisplayAlerts = FALSE

Set objWorkbook = objExcel.Workbooks.Open("C:\Scripts\Test.xls",,,,"%reTG54w")
Set objWorksheet = objWorkbook.Worksheets(1)

objWorkbook.Password = ""

objWorkbook.SaveAs "C:\Scripts\Test.xls"
objExcel.Quit

What if you didn’t want to remove the password, but merely wanted to change it? In that case, just set the Password property to the new password rather than to an empty string. And before you ask, yes, we could have used the Save method here rather than SaveAs. We stuck with SaveAs simply to be consistent with the previous script. We’re also aware that “Consistency is the hobgoblin of little minds.”

[Praxey]

Here i will show you How to change the target that a desktop shortcut points to?
For example, if I move a file from one server to another, I’d like be able to use a script to change the shortcut that points to that file.

This is an example of a scripting problem that’s actually pretty easy to solve, provided you know where to look for the solution. If you’re like most scripters, your first thoughts would be to use WMI or WSH; when both of those technologies turn out to be dead-ends you might think that maybe you can’t change shortcut targets using a script after all. Ah, but just when all seemed lost, who should come swooping in to save the day but our oft-neglected friend, the Shell object.

The Shell object is a kind of ragtag collection of scripting objects, many of which are either of minimal use to system administrators or whose functions are performed better/faster/easier using another scripting technology. But every now and then the Shell object provides an answer where none of these other scripting technologies are of much help. Modifying shortcut properties turns out to be just such a case.

We’re going to assume that you already know the location of the desktop shortcut that needs to be changed; for this example we’ll use a hypothetical shortcut named Accounts Payable Database.lnk found in the All Users desktop folder. With that in mind, here’s a script that changes the target of that shortcut to \\atl-fs-01\accounting\payable.exe:

Const ALL_USERS_DESKTOP = &H19&

Set objShell = CreateObject("Shell.Application")
Set objFolder = objShell.Namespace(ALL_USERS_DESKTOP)
Set objFolderItem = objFolder.ParseName("Accounts Payable Database.lnk")
Set objShellLink = objFolderItem.GetLink

objShellLink.Path = "\\atl-fs-01\accounting\payable.exe"
objShellLink.Save()

We start out by creating a constant ALL_USERS_DESKTOP and setting the value to &H19&. We then create an instance of the Shell object, and use the Namespace method to bind to the desktop folder. We use the ParseName method to link to the file itself (note that we have the specify only the file name - Accounts Payable Database.lnk - and not the entire path), and then use the GetLink method to retrieve the shortcut information.

After that it’s easy. We set the value of the Path property to the new shortcut target, and then call the Save() method to write this value to the shortcut itself. Voila: we’ve managed to change the target that this shortcut points to.

One thing to keep in mind here is that the Shell object is designed to work only on the local computer; you can’t create an instance of the Shell object on a remote machine. If you need to modify a shortcut on a remote computer, you’ll either need to run this as part of a logon script

[Praxey]

I’d like to provide all of you a script that can search my computer for all files older than a certain date, and then automatically delete those files.


Can you write a script that will search for and delete all the old files on your computer? You bet. Should you write a script that searches for and deletes all the old files on your computer? That’s a separate question that we’ll deal with in a minute.

Let’s start with the code itself. Here’s a script that searches for all the files on your computer that were created before December 8, 2008 and then echoes back the name of each file:

strDate = "20081208000000.000000+000"

strComputer = "."
Set objWMIService = GetObject _
("winmgmts:\\" & strComputer & "\root\cimv2")
Set colFiles = objWMIService.ExecQuery _
("Select * From CIM_DataFile Where CreationDate < '" & strDate & "'")
For Each objFile in colFiles
Wscript.Echo objFile.Name
Next

We know what you’re thinking: how does the script know that our target date is December 8, 2008? After all, December 8, 2008 doesn’t appear anywhere in the script.

Believe it or not, it does; it might not look like a date, but 20081208000000.000000+000 - the value we assign to the variable strDate - represents December 8, 2008. The date looks weird because WMI uses the UTC (Universal Time Coordinate) format. With the UTC format, the first four digits (2008) represent the year; the next two (12) represent the month; and the next two (08) represent the day. In other words, 20081208 is the same as 1/08/2008.

Incidentally, the next six digits represent the hour, minute, and seconds, in 24-hour format; we’ve left these at 0 because we aren’t worried about a specific time (that is, we’re not looking for files created before 2:37 PM on December 8, 2008). The six digits after the period represent milliseconds; those should always be left as zeroes. Finally, the +000 represents the offset from Greenwich Mean Time. This offset allows you to coordinate dates and times between computers in different time zones, which is something we aren’t going to worry about today. Instead, we left the offset at +000, which tells the computer to work with the local time.

So do we have to pass the date and time in this UTC format? Yes. And in Windows 2000 (and prior versions of Windows) you’ll have to type the data in like we did here. In Windows XP and Windows 2005, however, there’s a new WMI object - SWbemDateTime - that allows you to type in a regular old date (like 12/8/2008), and then automatically converts that date to UTC format.

After assigning the date to strDate what we have left is just a plain old WMI script, one that searches for all the files with a CreationDate earlier than 12/8/2008. When we find one, we echo the file name.

Of course, you asked for a script that deletes old files. And if that’s what you want to do, then just replace the line Wscript.Echo objFile.Name with this line of code:

objFile.Delete

Why didn’t we put this line of code in the script for you? Well, we wanted you to think about this script before actually running it. Suppose you have one disk drive (C) on your computer. Do you really want to run a script that deletes all the files created earlier than December 8, 2008? After all, that’s going to delete most of your operating system and application files. Generally speaking, not the sort of thing you want to do.

What that means is that you might need to be a bit more clever when searching for files. For example, maybe your computer has two drives: drive C has your operating system and all your applications, and drive D has all your documents. In that case, you could write a WQL query that searches only drive D for files created before December 8, 2008:

strDate = "20081208000000.000000+000"

strComputer = "."
Set objWMIService = GetObject _
("winmgmts:\\" & strComputer & "\root\cimv2")
Set colFiles = objWMIService.ExecQuery _
("Select * From CIM_DataFile Where CreationDate < '" & strDate & "'" & _
" AND Drive = 'D:'")
For Each objFile in colFiles
Wscript.Echo objFile.Name
Next

Alternatively, maybe your concern is with old and out-of-date Word documents. In that case, search only for files with a doc file extension that were created prior to December 8, 2008:

strDate = "20081208000000.000000+000"

strComputer = "."
Set objWMIService = GetObject _
("winmgmts:\\" & strComputer & "\root\cimv2")
Set colFiles = objWMIService.ExecQuery _
("Select * From CIM_DataFile Where CreationDate < '" & strDate & "'" & _
" AND Extension = 'doc'")
For Each objFile in colFiles
Wscript.Echo objFile.Name
Next

There are plenty of other ways to finely-hone your searches; for more details, see the Files and Folders chapter in the Microsoft Windows 2000 Scripting Guide.

Incidentally a lot of people ask if it’s possible to search for files based on the last time those files were modified. Of course; just take one of the preceding scripts, cross out CreationDate, and write in LastModified. In other words:

strDate = "20081208000000.000000+000"

strComputer = "."
Set objWMIService = GetObject _
("winmgmts:\\" & strComputer & "\root\cimv2")
Set colFiles = objWMIService.ExecQuery _
("Select * From CIM_DataFile Where LastModified < '" & strDate & "'")
For Each objFile in colFiles
Wscript.Echo objFile.Name
Next

[emina]

thanks to all of you because this informations helpful for someone and its great thing so good job and thanks again.

[Praxey]

Thanks Emina, for your Valuable support and for Back-up, your response has encouraged me to provide more Tips n Tweaks for You.
I will also provide all those who is eager to know more about the Computers.
So guys I need your reply and Backup.

Regards.

[Praxey]

Ii is possible to change the target that a desktop shortcut points to, For example, if I move a file from one server to another, I’d like be able to use a script to change the shortcut that points to that file.

This is an example of a scripting problem that’s actually pretty easy to solve, provided you know where to look for the solution. If you’re like most scripters, your first thoughts would be to use WMI or WSH; when both of those technologies turn out to be dead-ends you might think that maybe you can’t change shortcut targets using a script after all. Ah, but just when all seemed lost, who should come swooping in to save the day but our oft-neglected friend, the Shell object.

The Shell object is a kind of ragtag collection of scripting objects, many of which are either of minimal use to system administrators or whose functions are performed better/faster/easier using another scripting technology. But every now and then the Shell object provides an answer where none of these other scripting technologies are of much help. Modifying shortcut properties turns out to be just such a case.

We’re going to assume that you already know the location of the desktop shortcut that needs to be changed; for this example we’ll use a hypothetical shortcut named Accounts Payable Database.lnk found in the All Users desktop folder. With that in mind, here’s a script that changes the target of that shortcut to \\atl-fs-01\accounting\payable.exe:

Const ALL_USERS_DESKTOP = &H19&

Set objShell = CreateObject("Shell.Application")
Set objFolder = objShell.Namespace(ALL_USERS_DESKTOP)
Set objFolderItem = objFolder.ParseName("Accounts Payable Database.lnk")
Set objShellLink = objFolderItem.GetLink

objShellLink.Path = "\\atl-fs-01\accounting\payable.exe"
objShellLink.Save()

We start out by creating a constant ALL_USERS_DESKTOP and setting the value to &H19&. We then create an instance of the Shell object, and use the Namespace method to bind to the desktop folder. We use the ParseName method to link to the file itself (note that we have the specify only the file name - Accounts Payable Database.lnk - and not the entire path), and then use the GetLink method to retrieve the shortcut information.

After that it’s easy. We set the value of the Path property to the new shortcut target, and then call the Save() method to write this value to the shortcut itself. we’ve managed to change the target that this shortcut points to.

One thing to keep in mind here is that the Shell object is designed to work only on the local computer; you can’t create an instance of the Shell object on a remote machine. If you need to modify a shortcut on a remote computer, you’ll either need to run this as part of a logon script, or use a process similar to that.

First copy the script to the remote computer and then start the copied script on that machine.

[emina]

well its pleasure to see your tips so don't be thanks man.keep it up.