Import from Clipboard disabled when it shouldn't

[m.Th.]

0. Make sure that the Clipboard is empty or with a text in it (IOW a non-graphic content).
1. Start XnViewMP
2. Run another program (eg. MSPaint) in order to get a window open
3. Press Alt+PrtScr to copy the active window to the Clipboard
4. Go to XnViewMP

Expected:

The Edit | Import from Clipboard should be activated and the user has the ability to have the image of the captured window.

Actual:

The Edit | Import from Clipboard is disabled (grayed).


5. (optional) To test the capture go to Microsoft Paint and press Ctrl+V. The captured image should appear.


1000. (mandatory) Why I don't use the XnViewMP's Capture tool? Here's why: http://newsgroup.xnview.com/viewtopic.php?f=60&t=28452


Musings: Btw, why the Import from Clipboard is grayed???... IMHO this induces state management which is an unneeded burden/complication in the code. I would just leave it as is (always enabled) and I would check if I have a compatible Clipboard format only in OnClick handler.

[JohnFredC]

I would agree with the "always enabled" suggestion if there was also a responsive alert message when no compatible formats are available on the clipboard.

FWIW, sometimes simply acting on the MP UI will (re-)enable the import clipboard function.

The MP Import Clipboard "enabling" behavior is inconsistent and suggests a possible problem with the clipboard polling code, perhaps in the condition that triggers the polling activity itself...

[m.Th.]

I would agree with the "always enabled" suggestion if there was also a responsive alert message when no compatible formats are available on the clipboard.

FWIW, sometimes simply acting on the MP UI will (re-)enable the import clipboard function.

The MP Import Clipboard "enabling" behavior is inconsistent and suggests a possible problem with the clipboard polling code, perhaps in the condition that triggers the polling activity itself...

+1

Usually I try to avoid to poll external, non-controllable entities, especially when there isn't a clearly defined event to trigger the poll (the Edit Menu roll down perhaps?). There are way too many factors which can make the things to go wrong.

OTOH, WRT "no compatible formats" - if there isn't nothing, do nothing. It there is picture, paste it. It there is any format which we can render with ease (eg. text) create an image and render it. Also we can use the Text format as a last fallback from a more complicated / proprietary format. If all these fail, then throw a message box with 'Unknown clipboard format' or similar.

[xnview]

Sorry but i can't reproduce, 'import from Clipboard' is activated after a Alt+PrtScr

[m.Th.]

Sorry but i can't reproduce, 'import from Clipboard' is activated after a Alt+PrtScr

If I open XnViewMP and press imediately Alt+PrtScr I obtain the same (correct) behavior like you.

However if I do my steps, I stumble upon the bug in 100% of cases.

Also John has encountered the problem.

IMHO it has something to do with (de)activating of XnView and activating another application, combined perhaps with a previous non-graphic (text?) paste in the clipboard.

[xnview]

However if I do my steps, I stumble upon the bug in 100% of cases.

I can't reproduce On which OS?

[m.Th.]

However if I do my steps, I stumble upon the bug in 100% of cases.

I can't reproduce On which OS?

Yeah, most probably.

Unfortunately I understand you. On Windows (see my sig) the Clipboard Notification Chain is known to be unreliable. For ex. see the second paragraph from the first post from here.

Some examples here:

http://www.clipboardextender.com/defect ... tification
http://answers.microsoft.com/en-us/wind ... 1e2daf1007
http://www.realvnc.com/pipermail/vnc-li ... 59835.html
http://superuser.com/questions/317616/c ... nt-of-time

An acknowledgement from Microsoft:

http://support.microsoft.com/kb/941282/en-us

Also see here for common mistakes:

http://www.clipboardextender.com/develo ... -windows/6

...and a very very cute support request:

http://answers.microsoft.com/en-us/wind ... 98c0075522


Conclusion:

You depend on ALL open programs to process correctly the Clipboard Notification Chain in order to correctly enable the clipboard menu entry. Way way way too risky if you'd ask me.

IMHO it introduces a ton of support issues and an annoying behavior (...and perhaps leaving users?...). Basically, because of an unknown program which fiddles with the Clipboard and eats the WM_CHANGECBCHAIN and/or because of a crash / GPF (read: the said program doesn't remove itself from chain and leaves a ghost entry), the XnViewMP will never enable the 'Import from Clipboard' menu item.

The solution is simple: Leave the menu entry always enabled. Anyway I have a hard time to see the advantage of disabling it.

[xnview]

Strange, i'm on win 7 x64 too

If i enable always 'import clipboard' not very user friendly...

[m.Th.]

Strange, i'm on win 7 x64 too

It isn't strange - but it seems that I wasn't clear enough. It depends on what programs one runs on his computer. Let's take it slower:

Here is a comparative mock-up between how we think that it should be and how the actual Windows Clipboard Notification Engine works. It depicts how the Windows Clipboard notifies all the other Clipboard-aware programs when the user copies a picture from a program to clipboard: (scroll to see)

Clipboard Message Chain.png

Got it? The problem is that it is the Program B's responsibility to notify the Program C that "Hey! There is something in the Clipboard!" and NOT Windows's responsibility..

--------------------- take a breath here and re-read the above a little... ------------------------

And hence if the Program B...

- doesn't know that it should pass the message along because the Team B didn't know / didn't want to do it
and / or
- crashes
and / or
- when it closes doesn't remove itself from the Notification Chain and hence the Chain is broken
and / or
- it has a bug in the code which passes the message because of programmer / framework

...then the Program C will NOT receive any notifications from the Clipboard and the Menu entry will remain grayed forever. Yes, you know it now: The Program C in our case is XnView MP. And it isn't basically your fault.

It is more clearer now?

(For more technical details see the links from my previous post)

And then, you will ask, how Microsoft/Adobe manages to receive the notifications?
Answer: They use low-level trickery (they have access to undocumented APIs) to register themselves at the beginning of the Notification Chain. Any other good-behaving program is pushed back.

If i enable always 'import clipboard' not very user friendly...

I agree that IF the notification mechanism were reliable then it would be ok. But even then, a disabled "Import clipboard" resembles a lot this dialog window:

Error.jpg

A much better solution from all POV would be IMHO an always enabled "Import from Cliboard" item and in OnClick event to check for the clipboard format. And if the format is different from CF_BITMAP (or whatever...) then show a message like this:

"The format of the data which you try to import from the clipboard is incompatible with XnView MP. Please copy to clipboard a picture, a vector, a text or a compatible data format"
{Ok}

One of the basic GUI design rules is that the program should guide the users what to do next.

That's why I strongly recommend an always enabled menu item with a format check inside followed by an explicative message if necessary.