Clipboard Comparison and ANSI

[TSO_MB]

Hello Scooter Software Team,

I experienced a weird behavior of Beyond Compare (BC) by using the clipboard comparison. In some situations BC seems to use another character encoding as in a normal file comparison.

I will enclose the text files, so you can reproduce the issue. Just do the following, to get the same behavior:

1. Open a BC instance and compare Cmp1.Left.txt with Cmp1Right.txt.
2. Open another BC instance and compare Cmp2.Left.txt with Cmp2Right.txt.
3. Show only differences in both BC instances.
4. Select everything of the right side in the second BC instance and copy it to clipboard.
5. Select everything of the right side in the first BC instance and compare it with the clipboard content.
6. You should get a difference, if you search for e. g. 5157843. BC tells you, that the value of the property "CaptionML" has been changed. But if you check the first two instances for that difference, you will not find it. This is because there is no difference. BC obvious has simply used another encoding for the clipboard comparison.

I cannot explain this result and hope, you can help. The Version I use is 3.3.8 (Build 16340).

Kind Regards
Marc

[Aaron]

Thanks for the report. The behavior you are seeing is due to an issue with our clipboard handling, but these files are also not auto-detecting their encoding correctly since they appear to be OEM. It is very difficult to auto-detect OEM, so you would need to set this encoding manually in the Session Settings (or the upper status bar). If OEM is set correctly, then the clipboard should actually work, too.

Does this work if you set both sides to OEM first, then copy to clipboard and compare, then verify the clipboard comparison is Unicode.

[TSO_MB]

Hello Aaron,

You are right, if you say, the files are DOS/OEM encoded. BC uses ANSI for viewing the files. That never was a problem (except you use the clipboard comparison). Actually ANSI should be okay for viewing, but not Unicode, because the files are exported from a version of Microsoft Dynamics NAV, which is not able to handle Unicode. Nevertheless your hint with the session settings works great. I changed the settings for text comparison from auto detect to ANSI. After that I started the comparison again. Though the encoding for the clipboard comparison still differs from the file comparison, now both sides (clipboard and selection) uses the same encoding. That means no difference for the CaptionML property of field 5157843 is shown anymore. And that is correct.

A little seldom is, that the encoding for the clipboard comparison still differs from the file comparison. If I check the CaptionML property of both comparisons, I clearly can confirm that.

But that doesn't matter anymore to me, because I can work now. Thank you for your tip.

Kind regards
Marc

[Aaron]

Hello,

Instead of switching from Auto-detect to ANSI, please try OEM. This should let the text display correctly and also then correctly work with the clipboard. The clipboard itself is unicode, which is why it needs to detect as that once text has been placed in it and then pulled out.

[TSO_MB]

Hello Aaron,

I tried it out. The result is very similar to the first one (also see enclosed screenshots). But one thing is better: If you use DOS/OEM the file comparison views the umlaut "ae" within the German word "Waehrungsfaktor" correctly. The clipboard comparison still has some problems with it. But since the view of that umlaut is in the same manner for both sides, at least no difference appears anymore. If you do the same clipboard comparison with auto-detect settings, a difference will appear. You also can see that the encoding of each side differs. Of course you can switch the encoding manually to OEM. Than no difference appears. But even if you do so, the representation of the umlaut is not correct. Perhaps future versions of BC will handle this better. But for now your workaround will help. Thanks again for that.

Kind regards
Marc