DonationCoder.com Software > Post New Requests Here

IDEA: Clipboard Chain broken notifier

<< < (2/3) > >>

tranglos:
Maybe just a question - if the clipboard chain gets broken, does it break all links or just ones "after it" (if this is how it works).
-springro (May 25, 2007, 05:58 AM)
--- End quote ---

As I understand the relevant MS documentation, the application gets added to the front of the list, so it would break all previous links in the chain. Applications that register themselves for clipboard monitoring later should not be affected.

Does a new application launching that uses the clipboard chain automatically go to the end of the list?
-springro (May 25, 2007, 05:58 AM)
--- End quote ---

To the beginning of the list, actually, and it is responsible for doing two things:
1. It must forward clipboard messages to the next application in chain
2. It muat cleanly remove itself and restore the chain when it stops monitoring the clipboard.

Failing to to either will break the chain.

Just wondering if when an application is started can affect how often it would be affected by other applications.  This might be useful to add a simple application that checks for something getting added to the clipboard every time CTRL+C is pressed.  At least I think this should be easy in Autohotkey, just add a pass through script for CTRL+C and monitor for a clipboard change.  If it receives a CTRL+C, but no change report, there may have been an issue.
-springro (May 25, 2007, 05:58 AM)
--- End quote ---

Just a reminder that Ctrl+C  is only one of many ways of copying stuff to clipboard.

tranglos:
This is probably tangential to your question, but I wanted to raise an issue that's rarely considered when discussing clipboard managers (and the reason I never use one ;)) Running a clipboard manager is a huge security problem if you also use a password manager or have a habit of copying/pasting passwords. The reason why is obvious; finding a solution is less so.

As far as I know, ClipMate is the only clipboard manager that behaves responsibly, but it requires cooperation from the password manager. ClipMate's author came up with a truly genius solution for password managers to tell any other program that it must not capture a particular clip. The way to do this is to register a special clipboard format, for which ClipMate checks. If clipboard contains data in this format, it will not capture the clip. It's awfully simple and can be easily implemented in any Windows program:

http://www.thornsoft.com/developer_ignore.htm

I use this technique in my Oubliette password manager, but it does depend on the clipboard manager checking for this condition and honoring it. Since most programs probably don't do that, I implemented a different (optional) technique as well. You guessed it: I intentionally break the clipboard chain. Just before Oubliette copies a password to clipboard, it registers itself in the chain, and then does not forward the clipboard notification to the next app in chain. Immediately after that the chain is restored.

This prevents *any* clipboard extender from capturing the clip, but is admittedly a heavy-handed approach, optional for those who worry about this sort of thing. It seems to be an interesting case when a momentary breaking of the clipboard chain is intended and quite beneficial.

justice:
Most clipboard managers allow you to specify exclusions to programs such like your password manager?

tranglos:
Most clipboard managers allow you to specify exclusions to programs such like your password manager?
-justice (May 25, 2007, 08:32 AM)
--- End quote ---

I don't know if they do, and I don't know how it could be implemented. When an application is notified about change in clipboard data, there is no way to know "who" put the new data on clipboard. The clipboard manager cannot tell if you copied from Word or from a password manager. At least I don't know any Windows APIs that provide that information.

(This is also a generic problem with Windows APIs: the messages applications send to each other do not sxpecify the sender. If an app gets a "COPY" message, for example, it cannot know if the user clicked Edit->Copy or a trojan horse program is trying to copy some sensitive data.)

thornsoft:
All you ever wanted to know about the Clipboard... :)
-lanux128 (May 24, 2007, 09:43 PM)
--- End quote ---

That's some seriously defective clipboard handling, and is the sort of thing that can and does cause clipboard chain problems in the first place.  The code on that article does not pass clipboard messages, nor does it handle the WM_CHANGECBCHAIN message.

My article pre-dates this one by a year, and properly explains how to handle the clipboard messaging, as does the SDK.
http://www.thornsoft.com/developer_clipboardviewer.htm
Also see (clipboard mistakes in general):
http://www.thornsoft.com/developer_commonmistakes.htm

To the OP: while a noble idea, your stand-alone app would only notify you if your app were disconnected from the chain, and can't detect breaks further down the line.
Suppose the chain looks like this:

Outlook
Foobar App
Clipboard Toy

And you launch your monitor, and you have:

Monitoring App
Outlook
Foobar App
Clipboard Toy

Now Foobar quits, and doesn't remove itself properly.
Now the chain looks like this:

Monitoring App
Outlook

But you can only see the top of the chain. How are you going to know that the Clipboard Toy is disconnected? You can't.

Navigation

[0] Message Index

[#] Next page

[*] Previous page