We envision NoteFrog as a Notes keeper and not a clipboard extender (since most people already have their own “favorite” clipboard tool). The primary purpose for NoteFrog having automatic clipboard capture capability is to allow you to easily capture a series of clips as notes. That said, some people do use NoteFrog as a clipboard extender. In that mode, they capture everything and then periodically move/copy the clips they want saved permanently, into a separate stack. In this mode, where most clips probably won’t become Notes, and will likely be discarded, making “trash” the active stack, facilitates easily “cleaning/removing” the unwanted clips.
So, why does NoteFrog sometimes stop capturing clips?
As stated above, NoteFrog is not intended to be a clipboard utility, but rather make it somewhat easy to capture content from the clipboard. It should* never fail to collect clips when used as intended – capturing a clip(s) on demand via a hot-key or direct capture command. It will also function perfectly in clip collection mode as long as all other programs in the collection chain “play fair”.
(The discussion below applies to the Windows clipboard, pre-Vista. When we no longer have to support XP based systems, we won’t have to worry about a “broken” clipboard chain although it is still possible that clipboard data be unavailable – see below)
The windows clipboard works like a game where the person on your left passes you a note and you read it and pass it along to the person on your right, etc.
What happens if someone doesn’t pass the message along or if someone quits but doesn’t tell the person ahead of them who to pass to now? (Or if you kill a program and they don’t get a chance to tell the person who to pass to)?
Assume there are no applications in the clipboard “chain”. Application A joins and the chain appears as follows:
-> A (“Windows” tells A when there is a new clip)
Application B then registers to join the chain. When it does so, it gets told who was previously at the front of the chain, and it is responsible for storing this information. The chain is now:
-> B -> A (“Windows” tells B when there is a new clip. B passes the info along to A.)
Lets have C and D join as well (in that order). The chain is now:
-> D -> C -> B -> A
Now, assume some text is copied to the clipboard. The system looks at who is at the front of the viewer chain and notifies them of the clipboard update. In this case it is D. D does what it needs to and then looks up who is next in the chain by referring to some information it has stored away somewhere. This is where problems can arise. If D is a badly written application (they do exist), then it might not have stored who was previously at the front of the chain when it joined (or maybe there is a bug and it gets the wrong information), and as a result C will not be notified of the update. Hence, we have a broken viewer chain, that means C, B and A are not told that the clipboard was updated.
Assume that the viewer chain looks as follows:
-> D -> C -> B -> A
B decides that it is time to leave the chain. So, it tells the system that it wants to be removed from the chain. The system then sends a message to the window at the front of the chain which says something like:
Remove B from the chain. A should now take B’s place in the chain.
Since D is at the front of the chain, it checks to see if B follows it in the chain. If not, it passes the message on to C. C sees that B follows it in the chain, so it updates its internal structures and now records A as following it in the chain. The chain is now:
-> D -> C -> A
Of course, this removal process is prone to failure. Say D did not pass the deletion message on. The chain remains as:
-> D -> C -> B -> A – (notice A is NOT receiving messages, since B has been removed)
But, when C tries to send the clipboard update notification to B what will happen? If B has exited then A will not get the notification. If B has not exited it might choose to ignore the notification as it has no obligation to pass it on since it is not part of the chain. Hence, we have a broken chain and A will most likely not be notified of clipboard updates.
Now, imagine that B decides to rejoin the chain. Then we will have:
-> B -> D -> C -> B -> A
This is actually:
-> B -> D -> C -> B -> D -> C -> B . . .
In other words, we have a loop in the viewer chain. Not only will A not be notified of updates, but the update notification will spin between B, D and C continuously!
There is no easy way to fix this dilemma, since there’s no easy way to determine who are all the participants in the chain – you only know the person before and after you.
For the most part, “fixing” the chain, doesn’t really fix it, it merely recreates it with the program doing the fix placing itself at the front of the list. This MAY be a fix, depending on the makeup of the chain, but more likely it “fixes” the chain for that program only. There’s no guarantee it fixes it for everyone.
So yes, a program (NoteFrog) can periodically move itself to the front of the chain. But that will still leave a possible mismatch between NoteFrog and other programs in the chain.
*It is also possible for a program to “hold” the clipboard so NO other program may get data from the clipboard. In that case, even refreshing the clipboard chain is not a solution, you must find the problem program and kill it. Or, when all else fails, reboot.