August 28, 2003
By Karen Kenworthy
IN THIS ISSUE
What an evening! My baby brother, Kevin, the high-powered Washington D.C. attorney, is home for a brief visit. So yesterday, much of my family gathered at Mom and Dad's house to celebrate.
Once again my parent's home was a full house -- full of life and laughter. Kevin brought his three sons. My other brother, Bill, drove over from a nearby town, along with his wife, four children, two grandchildren, and his son-in-law.
We missed Kevin's wife and two daughters (the busy girls couldn't get free this time). And Bill's two oldest sons couldn't make the party (one is off to school, the other had to work). But we ate their share of the barbeque, and told embarrassing stories about them in their younger days. :)
After such a full night, it was hard to wake up this morning. And that's ironic. Recently I've been struggling with a few sleepy programs, trying to find the best way to wake them from their slumbers ...
Have you ever launched a program, only to find out later that another copy of the same program was already running? I sure have. I can easily end up with half a dozen copies of a program (what programmers call "instances" of the program), all running at the same time.
Much of the time, an extra instance or two is pretty harmless. If I accidentally launch the Windows Calculator, when another copy is already running, I waste a few bits of my computer's memory. But no harm is done.
And often, a second copy of a particular program is real handy. Right now twelve instances of my web browser are running, allowing me to quickly switch between web site's I've recently visited but haven't fully explored. Running two instances of my word processor makes it easy to copy text from one document to another.
But rarely, running two copies of a single program can be dangerous. For example, consider software that burns data onto CD's. If you only have one CD recorder, running two such programs could result in digital chaos. Imagine the two instances, each trying to write different data to the same location on the disc.
The same is true of programs that perform low-level disk access, such as defragmenters. Only one such program should run at a time. Two or more instances can quickly turn a disk defragmenter into a disk scrambler. Other programs that require a limited resource, or manage a single data file (such as a database) don't deal well with copies of themselves.
Fortunately, most programs that don't play well with themselves prevent us from accidentally running a second copy. It's a pretty neat trick that saves lots of problems. Whenever we try to launch a second copy of these helpful programs, they ignore our request. Instead, the would-be second copy simply "wakes up" the overlooked first copy of the program, then bows out.
How do these clever programs perform this trick? I'm sure you know, a magician never tells. But a programmer will. :)
Microsoft recommends programs take these three steps, to prevent multiple copies of the program from running:
[Note: The next six paragraphs have a KNI (Karen's Nerdiness Index) rating of 2.0, out of a possible 5. Do not read while driving, or operating heavy equipment.]
Step 1: First, the program must find out if another copy of itself is already running. This is easy for programs written in the Visual Basic programming language. They simply check the value of a built-in variable called "App.PrevInstance". If it has a value of zero, the program knows it's the first of its kind and it's safe to run. If the variable has any other value, another copy of the program is already running.
A program written in another programming language must do a bit more detective work. It must search Windows' list of on-screen windows, looking for a main window that's like its own. [I tried, but I could only figure out how to use the word "windows" three times in that sentence.] If it finds a twin, the searching program is a duplicate.
Step 2: OK, a program knows it arrived late to the party. It's the second instance, and has to go. But before it leaves, it should "activate" the first instance of itself.
Activating an instance has two important effects. If the activated program's main window was minimized, it is restored to its original size and location. That window will also rise to the top of our computer desktop, appearing above all other on-screen windows and other images. Now we can see what the neglected, original instance was doing.
Finally, an activated instance receives Windows' "input focus". This means it will be notified of all subsequent keystrokes and mouse events. Now we not only see our prodigal program, we can communicate with it!
Step 3: The duplicate instance ends, leaving the original instance to do our biding.
Not So Fast
Pretty cool, isn't it? This technique saves memory and time, and can even prevent damage to our data.
Unfortunately, Microsoft's trick doesn't always work. To see why, let's peer through some computer windows ...
We've all seen windows, those on-screen rectangles where programs display information. Some are large, even covering the entire computer screen. Others are small, perhaps reduced to a small button on the task bar. And, of course, you'll find windows of every size in-between these two extremes.
Programs can also create special windows that are invisible (and make once-visible windows disappear) Not even Windows itself can pull back the curtain and reveal these hidden windows. They never appear on-screen, as long as the program that controls them wants to keep them under wraps.
Why would a program create a hidden window? It does sound pointless, at first. But a window is more than a place for program's to display text and graphics. Windows also allow programs to communicate with one another, via small bits of data called "messages". Often programs create hidden windows just for this sort of communication. And they'll hide those windows, to avoid confusing any humans who might be lurking nearby.
There's one more common reason a window might be hidden. When a program displays an icon in the Windows System Tray (the collection of icons in the lower-right corner of your desktop), it often hides its main window, removing it from public view. Only when the System Tray icon is clicked, or some other triggering event occurs, does the program reveal its main window.
And now you know why I've recently had trouble, waking some sleeping windows. Many of my Power Tools programs can be told to use this System Tray trick, hiding their windows until needed.
If you accidentally launch a second copy of one of these programs, it should try to activate the original instance. But if that instance is sleeping, with its windows hidden behind a System Tray icon, the activation will fail. What is a programmer to do?
Fortunately, there's a solution to this problem. And I've put it to work in the new version of my 'Net Monitor program.
Now, when you launch a second copy of the 'Net Monitor, it no longer tries to activate the (possibly hidden) window of the first instance. Instead, it plays a trick. The second instance sends a short message to the original instance's main window, making it think the user has pressed the F24 key.
Now unless your keyboard is very wide, you may not have realized Windows defines a total of 24 "F", or Function keys (F1 through F24). But it does. And the latest version of my 'Net Monitor program responds to this key, by activating its own main window, unhiding it if necessary.
So there it is. Once the phony F24 key has been received, the original copy of 'Net Monitor awakens. The duplicate copy of the program, after sending its message, silently slips away. Pretty cool, isn't it? :)
I'll soon be adding this nice feature to other Power Tools. In the meantime, if you'd like to try this new version of the 'Net Monitor, drop by the program's home page at:
If you'd like to learn more about the hidden windows lurking behind your monitor's glass, try my recently-updated Window Watcher program:
It reveals which program created each hidden (and visible) window, displays the title given that windows, and reports lots of other arcane, nerdy-type information too.
And if you're a curious programmer (and aren't we all <grin>), check out both programs' free Visual Basic source code too. You'll see exactly how this new feature is made to work, and discover some other programming tricks too!
Better yet, get the latest version of every Power Tool, including the new 'Net Monitor and Window Watcher, on a shiny CD. The disc also contains three bonus Power Tools, not available anywhere else. You'll find the source code of every Power Tool, every back issue of my newsletter, and a even some of my original Windows Magazine articles. The CD even includes a special license that lets you use your Power Tools at work.
Buying a CD is also the easiest way to support the KarenWare web site and this newsletter. To find out more, visit:
There's more to say about the new 'Net Monitor, and few other surprises ready to spring. But they'll have to wait until we meet again. In the meantime, give your loved ones a hug. And if you see me on the 'net, don't forget to wave and say "Hi!"
Power Tools Newsletter
- Directory Printer v5.4.4 Adds Unicode Characters Support
- Replicator v3.7.6 Eradicates Bug that caused Error 3
31760 Verified Subscribers
Subscribe to receive new issues of the newsletter about Karen and her free Power Tools.Click here to Subscribe