Encoding - Polish and Russion code page entry broken in 2.0.9

[simonsteele]

Original issue 48 created by simonsteele on 2008-04-28T00:37:49.000Z:

What steps will reproduce the problem?

1. press R-alt + 'a', R-alt + 's' etc.
2. Characters ą,ś ... should appear

3. $!@#$@! apears... (some other symbols)

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system? 2.9 (unstable)

Please provide any additional information below.

[simonsteele]

Comment #1 originally posted by simonsteele on 2008-06-09T22:31:35.000Z:

This is a very important problem, because people who write in Polish cannot enter diacritic characters (like ą,ę,ó etc.).

[simonsteele]

Comment #2 originally posted by simonsteele on 2008-10-30T09:27:51.000Z:

In the other bug it was mentioned that this occurred after a specific fix was made, can you pinpoint the version or build where it stopped working or just the first 2.0.9 release? I don't have an easy way to reproduce this yet as I don't have a polish install, but I'll see what I can do.

[simonsteele]

Comment #3 originally posted by simonsteele on 2008-10-30T13:35:32.000Z:

Currently I'm working with a version: v2.0.8.718-basie and I haven't any problems with entering Polish characters. I think, this is the last version which worked ok.

In Polish keyboards, specific Polish characters (ą, ę, ó, etc.) are entered by pressing letters (ex. a, e, o) with a right Alt. In the release "basie" I get Polish characters, next releases show strange symbols (please see an attachement - a screenshot made with the last release of the PN).

[simonsteele]

Comment #4 originally posted by simonsteele on 2008-11-06T09:12:49.000Z:

<empty>

[simonsteele]

Comment #5 originally posted by simonsteele on 2008-12-09T21:46:54.000Z:

Issue 104 has been merged into this issue.

[simonsteele]

Comment #6 originally posted by simonsteele on 2008-12-09T22:34:30.000Z:

Issue 237 has been merged into this issue.

[simonsteele]

Comment #7 originally posted by simonsteele on 2009-01-13T12:58:19.000Z:

The issue was introduced in 2.0.9.771. The last one working fine was 2.0.8.718.

[simonsteele]

Comment #8 originally posted by simonsteele on 2009-01-17T15:31:40.000Z:

This is caused by the build of Scintilla that Programmer's Notepad is now making, if you drop the SciLexer.dl from 2.0.8 on top then you get the correct behaviour (but lose the new regular expressions support).

I can now reproduce this so am working on it!

[simonsteele]

Comment #9 originally posted by simonsteele on 2009-01-17T15:57:36.000Z:

Ok, the change is something in Scintilla, it occurs using every public Scintilla build since 1.75 with PN.

[simonsteele]

Comment #10 originally posted by simonsteele on 2009-01-17T16:27:26.000Z:

Final update for today, the current Scintilla versions work OK if the window is created Unicode, and not otherwise. It appears that the unicode window support added in Scintilla 1.75 broke the existing non-unicode version. Just using CreateWindowExW doesn't seem to do the necessary, I think the class needs registering through RegisterClassExW which is difficult to do with WTL. May have to wait until the whole project builds as Unicode ok.

[simonsteele]

Comment #11 originally posted by simonsteele on 2009-01-18T00:22:47.000Z:

I think this may be relevant. I routinely enter alt+0149 to get a right quote. This is broken in 2.0.9, and replaced with a control-code [em](ASCII 25 I think). Mark

[simonsteele]

Comment #12 originally posted by simonsteele on 2009-01-19T23:42:22.000Z:

Ok, I finally worked out a good fix for the next release, with the Scintilla window as Unicode inside the mainly non-unicode process. Character insertion finally works as it used to!

The complexity will all go away in 2.0.11 when we move to a full Unicode build.

[simonsteele]

Comment #13 originally posted by simonsteele on 2009-01-27T19:10:36.000Z:

Issue 307 has been merged into this issue.