Current cvs, non-unicode build
unicoder.cpp is getting its idea of the internal
codepage by calling "getDefaultCodepage()" (from
common/unicoder.cpp function getDefaultEncoding).
This function is implemented in codepage.cpp as using a
variable which was set by the Edit/Options/codepage tab.
So, we're letting the user's chocie of default codepage
drive what unicoder thinks the internal windows
I think this is badly broken, because unicoder needs to
convert to the windows internal codepage -- the one
that ExtTextOut believes in, because the user is going
to see what ExtTextOut displays.
So if you set the codepage to anything besides the
system default, you have (a) told winmerge how to
interpret most 8-bit files (which is fine), and (b)
told winmerge what the windows codepage is, which is
not fine -- now you are in WYSINWYH* hell, because you
are playing a make believe game that ExtTextOut is not
playing with you. :)
*What You See Is Not What You Have (I just made this up :))
However, I've just figured this out, so I'm open to
debate, discussion, or being proven wrong.
Log in to post a comment.