|
|
|
| Top | Optimizing Windows | Getting Started | Power Windows |
By John Woram
I RAN OUT OF space before I ran out of things to say last month. Since next month's Enterprise Windows section will discuss backup and restore issues, this seems like a good time to further complicate the long-filename (LFN) conundrum.
We've all been told how much richer our lives would be if we could just store our files with names such as "Rambling description of an otherwise cryptic.DOC" instead of having to make do with RAMBLING.DOC. This feature may be just what we need; then again, it may not. Many users have discovered the inverse relationship between filename length and readability. I've foundthat beyond 30 or 40 characters (your mileage may vary), readability falls off sharply.
Even if you're a light user of long filenames, you may be surprised to discover how many of them find their way onto your hard disk. I did a tally while I was setting up a new Windows 95 system, and here's what I found: 168 after I installed Win95, 637 after I installed Microsoft Plus, 811 after I put in Microsoft Office 7.0 and 823 after I used Microsoft Exchange for the first time. To get a rough idea of your own LFN file count, open a DOS window, type the first line shown here, press the Enter key and then type the next line:
dir C: \*~?.* /s
dir C: \*~??.* /s
These search strings find every 8.3 filename that includes a tilde followed by one or two digits, something the Windows 95 Explorer's Tools/Find option won't do. But even this technique won't turn up every long filename.
Why not? To answer a question with a question: When is a short filename a long filename? Okay, it's a trick question. The answer is, "Sometimes." To see for yourself, save a file with a name such as FileName.Xyz (note the upper/lowercase mix), then open a DOS window and do a directory listing. You'll find FILENAME.XYZ on the left side of the listing, and FileName.Xyz on the right. This is your clue that Windows 95 has given this file two directory entries, the first in the conventional 8.3-compliant format and the second in the long filename format. In this case, the latter serves no other purpose than to preserve the upper/lowercase style. Because a long filename such as FileName.Xyz doesn't exceed conventional 8.3 length specifications, there's no tilde in its short version, so the DOS search described earlier won't turn up this sort of file.
If you rename your FileName.Xyz file as FILENAME.XYZ, you'll find that a DOS directory listing now shows the all-caps format on both sides of the listing, which might make you think only one directory entry is used. But you'd be wrong. In this case, the original two entries are retained, although both are rewritten with the new all-caps filename. To recover that second block, rename the file WHATEVER.XYZ. By doing so, both of the former directory blocks are marked as available, and a new one-block entry is written for the new filename. You must enter this in all uppercase characters or you're right back where you started.
These "wasted" directory entries are a non-issue, though, unless your root directory contains many very long filenames. Remember, your root directory has room for only 512 entries, or just 64 entries if each one is a long filename that needs eight directory blocks. But if either of these unlikely scenarios applies to you, you really should think about taking a long vacation. While you're away, maybe someone will clean up your system for you.
If the default LFN truncation style is not to your liking, you have an alternative. The Microsoft Windows 95 Resource Kit describes a "friendly alias name" system in which the first truncation creates an 8.3-compliant filename consisting of the first eight characters in the LFN. Thus, WretchedlyDullFileName.EXE becomes WRETCHED.EXE instead of WRETCH~1.EXE. If you have another LFN that starts with the same eight letters, it will be called WRETCH~1.EXE.
To implement the friendly-alias system, execute the Registry Editor (REGEDIT.EXE) and sequentially click the plus signs next to the following folders: HKEY_LOCAL_MACHINE, System, CurrentControlSet and control. Then click on the FileSystem folder and select Edit/New/Binary Value. Type NameNumericTail in the New Value 1 box, press Enter twice, type a single zero (which will appear as 00) in the Value data window, click on OK and exit the Editor. The next time you start Windows 95, a "friendly" alias name will replace the usual six-characters-plus-tilde-1 convention.
If you like long filenames but don't often use the same eight characters for multiple files, you may prefer this format. But remember, the ~x style provides a nice visual clue that you're looking at a long filename in its short format. This may make a difference if the file finds its way to a DOS 6.x or earlier system. In this case, the tilde serves as a warning not to rename the file because doing so will sever its link to the long filename blocks.
Here's another LFN consideration for those whose diskettes commute between a Windows 95 system and a DOS 6.x system. If you insert an unlabeled diskette in the A: drive and type VOL or LABEL at a command prompt, you'll see the message "Volume in drive A has no label," which is just what you'd expect. Reboot into DOS 6.x, though, and the message may change to "Volume in drive A is Cf," or some other puzzling two-character label.
The problem here is that all versions of MS-DOS scan the directory and recognize a volume label as the first entry whose volume attribute (e.g., bit 3 of byte 11) is set. If a block is part of a long filename, Windows 95 sets bits 0-3 of the same byte but is smart enough to ignore this configuration in its search for a volume label. MS-DOS isn't that clever, though, so when it finds the first long filename block in the directory, it thinks the block is the volume label.
The plot thickens. If the first LFN is ThisIsARatherLongFileName.xYz, the first three bytes in one of its LFN directory blocks are hexadecimal 43, 78, 00. The 4 in the first byte tells Windows 95 this is the final LFN block for the filename, and the 3 indicates the number of occupied blocks.
But to MS-DOS 6.x and earlier, the same three numbers look like the letters Cx followed by a null character. So, MS-DOS 6.x reports the volume label as Cx (the null prevents additional characters from appearing as part of the label). But why Cx? Because the complete LFN sits in three blocks, in the sequence shown here:
xYz
LongFileName.
ThisIsARather
The first letter -- the C in Cx -- lets you know how many directory blocks the long filename occupies (A = 1, B = 2 and so on). The x just happens to be the first letter in the last block. But because the blocks are written into the directory in reverse sequence, it's the first block that MS-DOS finds.
An inexperienced DOS 6.x user might try to change this odd-looking label to something more meaningful, not realizing it would wreck the long filename data actually contained in this erroneous volume label block. Fortunately, any attempt to do so displays a Cannot Make Directory Entry message, for two reasons. First, as I mentioned earlier, Windows 95 sets bits 0-3 to specify a long filename. One of these bits (0) is the read-only attribute, which blocks any changes to the name. But even if this bit were cleared, MS-DOS 6.x doesn't know what to make of all those null bytes (00) in the LFN block. So it leaves them -- and the entire block -- alone.
Why not resolve the issue by bringing the diskette back to a Win95 machine and labeling it there? You can, but it won't solve the problem. The volume label is now written into the directory after the location of that LFN block. So, an old MS-DOS system will still find the LFN block first, and therefore it will never get as far as the real volume label. If there's only one long filename ahead of the volume label in the directory, you may be able to give that file a new name -- any new name -- then rename it back to its original moniker. That should move it to a location beyond the volume label in the directory. However, if there's more than one long filename in the directory, this probably won't work because the second renaming operation may reuse the directory blocks just vacated by the first renaming. Therefore, DOS 6.x or earlier will still find erroneous information that prevents it from getting to the real volume name.
To steer clear of this problem, just remember to label any diskette before you write files to it -- unless, of course, you want to continue annoying your DOS 6.x colleagues.
Senior Contributing Editor John Woram is the author of Windows Configuration Handbook (Random House, 1993). Contact John in the "Optimizing Windows" topic of WINDOWS Magazine's areas on America Online and CompuServe. To find his E-Mail ID Click Here
Is this a bug or a feature? If you run Windows 95 and need to send a diskette to someone who doesn't, page 689 in the Windows 95 Resource Kit explains how to enable the Windows 3.1 file system. Here's one of the options in its entirety:
At the command prompt, run scandskw /o to remove long filenames and all extended file attributes from the disk. To remove long filenames from removable disks, include the drive letter with the command; for example, scandskw /o a:
Caution: If you use scandskw /o to remove long filenames, ScanDisk will check all fixed disks and will repair disk errors without warning you. Changes made with scandskw /o cannot be reversed.
Depending on how you interpret the caution, you might think scandskw /o a: will perform as stated and hard disk errors may or may not be fixed. It's anyone's guess, though, because the caution doesn't cover the inclusion of a drive letter on the command line. You might guess that doing so would limit the action to just the specified drive.
Guess again. Scandskw /o a: does just what it says to drive A: and then some. It "fixes" your hard disk by truncating every long directory and filename on it -- without warning. And as the last line in the Caution puts it, changes made with scandskw /o cannot be reversed. Gotcha!!
| Top | Optimizing Windows | Getting Started | Power Windows |
By Jim Boyce
AS WE HURTLE toward the 21st century, some fundamental changes are transforming the way we interact with one another. Take mail. Forget licking postage stamps -- with e-mail, you can send your letters almost anywhere without paper, envelope or zip code.
Why is e-mail so attractive? First, it's cheap. All the commercial online services let you send and receive a certain number of messages for no additional cost beyond your monthly membership fee. It's also convenient. Just compose a message, click on the Send button and it's on its way.
Most importantly, e-mail is fast. An e-mail message can theoretically travel to the other side of the globe in seconds. In practice, it usually takes a little longer, but it's warp speed compared to ye olde surface mail.This month I'll answer some questions to help you send your regards to Aunt Agnes, who is day-tripping with her cellular-capable notebook in the Yukon.
Q: I'd like to start using e-mail from my home computer, but I don't have a clue about where to start. Do I need any special software or hardware? How do I get an e-mail account?
A: You'll need a modem and software. Buy either a 14.4Kb-per-second or a 28.8Kbps unit. External modems are easier to install than internal modems, but you'll have to make sure your PC has an available serial (COM) port. (There are parallel-port modems, but they're rare.)
If you belong to a commercial online service such as CompuServe (614-529-8990) or America Online (800-448-6364), you already have an e-mail account. E-mail features are built into these services' interface programs, so you won't need any additional software. Your monthly fee entitles you to send a certain number of messages each month at no extra charge, and the cost for additional messages is reasonable. Fees for basic service generally run about $10 per month.
If you're interested in e-mail only and don't want an online service account, turn to a long-distance phone carrier. MCI (800-388-5962), AT&T (800-242-6005) and Sprint (800-736-1130) all offer e-mail services. Of the three, MCI is the least expensive; its basic service, which includes 10 free messages per month, is free to MCI phone service customers and costs $5 for non-customers. The carrier you choose will provide the software you need.
A third option is to buy Internet access from an Internet service provider. Check with your local phone carrier, buy a copy of Internet in a Box or check the yellow pages under Internet. Typical monthly charges are competitive with commercial online services. Your Internet provider will likely furnish the software you need to access the Internet and your e-mail. Windows 95 users may want to buy Microsoft Plus for Windows 95. This add-on includes an Internet Mail provider that lets you use Microsoft Exchange (included with Win95) to access your Internet mail.
Here's a tip if you opt for Exchange: The Microsoft Fax service provider for Exchange hogs the modem line, preventing the Internet Mail provider from accessing the modem. If you use Microsoft Fax, place the Internet Mail provider in a different Exchange profile from Microsoft Fax.
Q: Can I send e-mail to a friend who uses a different online service.?
A: Yes you can. The phenomenal growth of the Internet has almost ensured you can send e-mail from almost any service to literally any e-mail address in the world by routing the message through the Internet. To send a message to someone on a different commercial online service, use the recipient's online account name, followed by the "@" symbol, then the domain name of the online service.
To send a message to me, for instance, use the address 76516.3403@compuserve.com. This is my CompuServe address in Internet format. Remember to change the comma you'd normally include in the recipient's CompuServe account number to a period. To send a message to my America Online (AOL) account, use JimBoyce@aol.com because "JimBoyce" is my AOL account name and "aol.com" is AOL's domain name. You can reach other e-mail accounts using a similar addressing method. To reach an account on MCIMail, for example, the user's MCIMail number with"@mcimail.com."
Your online service should offer a help file or other online reference to help you address messages to other services. You may need to preface the address with a special address identifier. On CompuServe, for instance, you need to preface all Internet addresses with the word "Internet," as in Internet: jimb@tigers.k12.cfa.org. If you can't find the information you need online to help you build the right address, contact the service's customer support.
Q: I've finally become comfortable using my Internet mail account, but I've found one real drawback: I can't use it to send document files. The messages have to be text-only. Isn't there any way to send documents and other types of binary files through the Internet?
A: Yes, but somewhat indirectly. You can't send a binary file through the Internet in the same way you send a binary file on CompuServe or an e-mail system on a local area network. Here's the trick: You have to convert the binary file to text and send it as text. The recipient then has to convert the message from text back to its original binary form.
Some Internet mail programs handle this translation from binary to text and back again automatically. You just attach the document to a message and send it. The e-mail program codes the message in ASCII characters that can be transmitted across the Internet. When you receive a message that contains a coded binary file, the program decodes it for you and it appears as a binary attachment.
Some e-mail programs, however, don't handle the translation automatically. Instead, you need to use a secondary program to convert the file to text, then attach the text to your message. Two common coding methods are MIME and UUCODE. You can find a DOS-based MIME coder/decoder on the Internet at ftp.andrew.cmu.edu: pub/mpack/. For a UUCODE utility, check out WinCode, which you'll find in the MS Windows Shareware forum on CompuServe (GO: MICROSOFT) and at ftp.cica.indiana.edu on the Internet.
Contributing Editor Jim Boyce is the lead author of Special Edition Using Windows 95 Communications (Que, 1996).
| Top | Optimizing Windows | Getting Started | Power Windows |
By Karen Kenworthy
Click Here to see a
20.7KB bitmap image of artwork
which goes with this article, entitled:
Making Macros
EVER WISH YOU were a programmer? You could eat pizza all day and night, and wash it down with Jolt Cola. You'd be able to read Martin Heller's Programming Windows column and understand every word. Best of all, the programs you use would behave just the way you want, thanks to your changes and tweaks.
Sounds like a dream, doesn't it? For the most part, it is. But no one can live indefinitely on pizza and Jolt. And no one understands everything Martin writes. But anyone can have custom-tailored applications.
By writing small programs called macros, you can change many applications. You can write macros to add features to an app, alter the way an existing feature works or remove features to increase security.
Each application has its own macro language, though Microsoft is gradually standardizing on a language called Visual Basic for Applications. Macro languages may be easy to learn and use, but they're very powerful. This month, I'll show you WordBasic, the macro language of Word for Windows, a.k.a. WinWord.
WordBasic is so powerful, WinWord's developers wrote portions of the program in the language. A collection of macros controls the actions performed in response to menu picks and toolbar button clicks. WordBasic is also easy to learn. In fact, you can write your own macros in the time it takes to read this column.
Let's start by making a simple change to the File/Open dialog WinWord 6.0 and 7.0 display. Normally, when you select Open, the File/Open dialog lists all the .DOC files in the current directory. If you want File/Open to list all files regardless of extension, you need to modify the macro named FileOpen. This macro runs automatically every time you select File/Open.
Close any documents you're working on and click on the New File button. From the Tools menu, select Macro to bring up the Macro dialog box. From the Macros Available In list box, select Normal.dot (Global Template). In the Macro Name box, enter FileOpen. The phrase "Opens an existing document or template" should now appear in the description box at the bottom of the dialog box. If not, make sure you spelled the macro name correctly.
You may think your next step is to click on a button labeled Edit. After all, your plan is to change the existing FileOpen macro. But there is no Edit button; instead, there's a button labeled Create, which indicates no macro with the name FileOpen currently exists. What's the deal?
Well, the developers of WinWord are a cautious lot. They didn't want to make it too easy for you to change the behavior of such important menu choices as File/Open. So they tucked these macros out of the way of idle hands. But your hands are anything but idle; I'll bet your mouse-button finger is getting itchy right now. So go ahead and click on the Macro dialog's Create button and see what happens.
With a little luck, you're now looking at a window containing the following lines of code:
Sub MAIN
Dim dlg As FileOpen
GetCurValues dlg
Dialog dlg
FileOpen dlg
End Sub
These are all the commands in the hidden FileOpen macro created by WinWord's developers. WinWord has conveniently copied the hidden FileOpen macro to the Normal.dot template, where you can see and change it. As long as this copy of FileOpen exists, it will override the original.
Before you start making changes to FileOpen, let's take a moment to examine it. As you can see, it contains only six lines. The first and last lines, Sub MAIN and End Sub, mark the beginning and end of the macro ("Sub" is short for Subroutine, another name for a macro). The four lines in the middle do all the real work. Here's what it all means:
Dim dlg As File-Open. This line "dimensions" a variable named dlg. "Dimension" (or "Dim" for short) is nerdspeak for "create" (they can't make it too obvious or everyone would be a programmer). So, in plain English, this line creates a variable named dlg.
A variable is just a place in your computer's memory where you can store data. You'll store the information for WinWord's File/Open dialog box in the new variable. The words As FileOpen at the end of the line tell WinWord how you'll use dlg.
GetCurValues dlg. This line causes WinWord to store the current, or default, File/Open dialog information in the dlg variable. GetCurValues is a built-in WinWord command designed for just this purpose.
Dialog dlg. Now you're getting down to business. WinWord's built-in command, Dialog, displays one of WinWord's standard dialog boxes. Because WinWord knows your dlg variable contains FileOpen information, it displays a File/Open dialog. It takes the dialog's initial, or default, entries from dlg.
Once WinWord displays the File/Open dialog, the macro halts temporarily. It won't carry out any more macro instructions until the user completes the entries in the dialog and then clicks on either its OK or Cancel button. Once the user clicks on either button, WinWord automatically updates the dlg variable to reflect entries the user made, and the macro continues.
FileOpen dlg. This line uses WinWord's built-in FileOpen command (not to be confused with our FileOpen macro) to actually open a file for editing. WinWord takes the information it needs from the dlg variable.
Pretty simple, right? Create a place to store FileOpen information, fill this space with default values, display the File/Open dialog and then use its information to open a file. As easy as 1, 2, 3, 4.
Dlg. Before you start making changes, let's take a moment to learn more about dlg, the FileOpen variable. It appears in all four lines of the standard FileOpen macro, and it will feature prominently in the change you're about to make. Like all FileOpen variables, dlg contains nine pieces of information, called properties, that you can view or change within a macro.
To refer to a property, combine its name with the associated variable's name, then in the middle add a dot ("."). For example, to refer to the Revert property of the dlg variable, you'd enter dlg.Revert. To refer to the variable's Name property, enter dlg.Name.
The Name property is the one you want. When the File/Open dialog is displayed, this property determines which filenames are listed. The default value of *.DOC causes all WinWord .DOC files in the current directory to appear. If you change this property before the dialog is displayed, the list will change. To do this, add the line dlg.Name = "*.*" right after the GetCurValues dlg line of the macro. Don't forget the quotes.
Because your goal is for WinWord to display files with any extension, you have to change the dlg.Name property to "*.*". You could just as easily set up WinWord to display files matching some other wildcard specification, such as *.CHP or MEMO*.DOC, by changing dlg.Name to that other wildcard specification.
On Error Goto Quit. Your macro is done, except for one detail. Test it by selecting File/Open, but instead of clicking on the dialog's OK button, click on its Cancel button.
Ugh. Not pretty, is it? The warning box you see indicates you decided not to open a file after all. But your macro blindly attempts to open a file anyway via its FileOpen dlg statement, which immediately follows the display of the dialog. What you need is a way to exit the macro without attempting to open a file, whenever the Cancel button is clicked. To do that, you must add two lines. First, type the line On Error Goto Quit right after the dlg.Name = "*.*" line you added before. Next, add the line Quit: (note the colon) just before the End Sub line.
The first new line tells WinWord what to do if it encounters an "error" such as the user clicking on the Cancel button. It directs WinWord to go directly to the line reading Quit: and skip all intervening instructions. In your macro, this means skipping the statement that attempts to open the file. The last new line (Quit: ) is a label that marks the place where the macro will resume after an error. Because Quit: is the last line of the macro, the macro simply terminates if an error occurs.
To preserve your Most Recently Used file list, add the line dlg.AddToMru = 1 after the Dialog dlg line. This fixes a bug that causes the AddToMru property (which causes files to be added to the File menu's Most Recently Used file list) to default to 0 (False). The line changes the property to 1 (True).
That's it. Save your new macro by selecting File/Save Template, and your work is done. Because you stored your version of the FileOpen macro in the Normal.dot template, it will be in effect whenever WinWord is running, regardless of which documents or templates are open.
If you prefer, you can store the macro in another template, making it effective only when that template is open and active. Just open the desired template and create the FileOpen macro following the steps above, with one change: When you create the copy of the original, hidden FileOpen macro, be sure to select your desired macro from the Macros Available In list in place of Normal.dot.
You can also click on the Organizer button to move or copy macros from one template to another. Or you can click on the Delete button to remove a macro from a template. If you remove the macro from all active templates, including Normal.dot, the File/Open menu choice will revert to its original behavior.
Once you've got this simple change under your belt, you're ready for bigger and better things. You may want to change the behavior of the Print toolbar button, causing it to print two copies instead of one. To do this, just add the line dlg.NumCopies = 2 right after the GetCurValues dlg line in the FilePrint Default macro. This is the macro WinWord calls whenever you click on the Print button.
Feel free to experiment with other menu choices, toolbar buttons and dialog properties. Get a copy of Microsoft Press' Word Developer's Kit. You'll find nearly 1,000 pages about WordBasic, plus a diskette with several sample macros.
Download the template file PWWORD.ZIP, which contains these macros.
Contributing Editor Karen Kenworthy is the author of Visual Basic for Applications, Revealed! (Prima Publishing, 1994) and the manager of the WINDOWS Magazine forums on America Online and CompuServe. Contact Karen in the "Power Windows" topic of these areas. To find her E-Mail ID Click Here
Property Name: Name
Purpose: The wildcard specification of files to appear in the list of available files, or the name of the document to be opened.
Default value: *.DOC
Property Name: ConfirmConversions
Purpose: If True, the Convert File dialog is displayed when a non-Word file is opened.
Default valueTrue
Property Name: ReadOnly
Purpose: If True, the file is opened read-only, preventing user changes.
Default value: False
Property AddToMRU
Purpose: If True, the opened file's name is added to the MRU (Most Recently Used) list at the bottom of the File menu.
Default value: True
Property: PasswordDoc
Purpose: The password of the document being opened.
Default value: Blank
Property: PasswordDot
Purpose: The password of the .DOT (template) file being opened, or associated with the document being opened.
Default value: Blank
Property: Revert
Purpose: If True, any unsaved changes to files with the same name as the file being opened are discarded, and the new file is displayed in the old file's window.
Default value: False
Property: WritePasswordDoc
Purpose: The password required to save changes to the document being opened.
Default value: Blank
Property: WritePasswordDot
Purpose: The password required to save changes to the .DOT (template) file being opened, or associated with the document being opened.
Default value: Blank
|
|
|