BBRUNER Patrickrefactor: one offered-encoding list, in EncodingRegistry
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
Fix casing of names for case sensetive FS.\nAdded a few TODOs. | 1 年前 | |
update .net 10 and nuget | 10 个月前 | |
refactor: one offered-encoding list, in EncodingRegistry The Preferences default-encoding combo box and the View > Encoding menu each carried their own list of encodings, and they had drifted: the menu lacked windows-1250 and windows-1252, and carried an "ANSI" row that the combo did not. Adding GB2312 for #688 meant editing both, plus a third place - the check-state lookup that maps the encoding a file is read with back onto a menu row. EncodingRegistry.OfferedEncodings is now the one list, and it documents the invariants both UIs depend on (resolvable by its own header name, no two entries sharing a code page, append rather than sort). Adding an encoding is a one-line change there. The menu rows are built from it at runtime by EncodingMenuBuilder rather than declared one by one in the designer. Each row carries the Encoding it stands for in its Tag, so the click handler applies whatever the clicked row carries (one handler, was five) and the check-state lookup compares against it (was a cascade naming every encoding). Rows are labelled with their header name, the same text the combo box shows, which retires five resource keys that were dead anyway - the constructor overwrote them before anyone saw them. Also fixes what GB2312 exposed in the legacy and XML readers, which advance their position per character by a per-encoding step: GetPosIncPrecomputed credited every encoding that is not UTF-8 or UTF-16 with one byte per character. GB2312 is the first offered encoding that is neither single-byte nor Unicode, so the position drifted on the first Chinese character and every later line began at the wrong offset. The step is now keyed on Encoding.IsSingleByte, and 0 ("measure the character") covers the variable-width case. Test coverage follows the seam: the list invariants are asserted once against the registry instead of per dialog, and the menu fixture is filled by the real builder, so it can no longer describe a menu the application does not build. | 1 个月前 | |
resources.de | 1 年前 | |
refactor: one offered-encoding list, in EncodingRegistry The Preferences default-encoding combo box and the View > Encoding menu each carried their own list of encodings, and they had drifted: the menu lacked windows-1250 and windows-1252, and carried an "ANSI" row that the combo did not. Adding GB2312 for #688 meant editing both, plus a third place - the check-state lookup that maps the encoding a file is read with back onto a menu row. EncodingRegistry.OfferedEncodings is now the one list, and it documents the invariants both UIs depend on (resolvable by its own header name, no two entries sharing a code page, append rather than sort). Adding an encoding is a one-line change there. The menu rows are built from it at runtime by EncodingMenuBuilder rather than declared one by one in the designer. Each row carries the Encoding it stands for in its Tag, so the click handler applies whatever the clicked row carries (one handler, was five) and the check-state lookup compares against it (was a cascade naming every encoding). Rows are labelled with their header name, the same text the combo box shows, which retires five resource keys that were dead anyway - the constructor overwrote them before anyone saw them. Also fixes what GB2312 exposed in the legacy and XML readers, which advance their position per character by a per-encoding step: GetPosIncPrecomputed credited every encoding that is not UTF-8 or UTF-16 with one byte per character. GB2312 is the first offered encoding that is neither single-byte nor Unicode, so the position drifted on the first Chinese character and every later line began at the wrong offset. The step is now keyed on Encoding.IsSingleByte, and 0 ("measure the character") covers the variable-width case. Test coverage follows the seam: the list invariants are asserted once against the registry instead of per dialog, and the menu fixture is filled by the real builder, so it can no longer describe a menu the application does not build. | 1 个月前 | |
refactor: one offered-encoding list, in EncodingRegistry The Preferences default-encoding combo box and the View > Encoding menu each carried their own list of encodings, and they had drifted: the menu lacked windows-1250 and windows-1252, and carried an "ANSI" row that the combo did not. Adding GB2312 for #688 meant editing both, plus a third place - the check-state lookup that maps the encoding a file is read with back onto a menu row. EncodingRegistry.OfferedEncodings is now the one list, and it documents the invariants both UIs depend on (resolvable by its own header name, no two entries sharing a code page, append rather than sort). Adding an encoding is a one-line change there. The menu rows are built from it at runtime by EncodingMenuBuilder rather than declared one by one in the designer. Each row carries the Encoding it stands for in its Tag, so the click handler applies whatever the clicked row carries (one handler, was five) and the check-state lookup compares against it (was a cascade naming every encoding). Rows are labelled with their header name, the same text the combo box shows, which retires five resource keys that were dead anyway - the constructor overwrote them before anyone saw them. Also fixes what GB2312 exposed in the legacy and XML readers, which advance their position per character by a per-encoding step: GetPosIncPrecomputed credited every encoding that is not UTF-8 or UTF-16 with one byte per character. GB2312 is the first offered encoding that is neither single-byte nor Unicode, so the position drifted on the first Chinese character and every later line began at the wrong offset. The step is now keyed on Encoding.IsSingleByte, and 0 ("measure the character") covers the variable-width case. Test coverage follows the seam: the list invariants are asserted once against the registry instead of per dialog, and the menu fixture is filled by the real builder, so it can no longer describe a menu the application does not build. | 1 个月前 | |
refactor: one offered-encoding list, in EncodingRegistry The Preferences default-encoding combo box and the View > Encoding menu each carried their own list of encodings, and they had drifted: the menu lacked windows-1250 and windows-1252, and carried an "ANSI" row that the combo did not. Adding GB2312 for #688 meant editing both, plus a third place - the check-state lookup that maps the encoding a file is read with back onto a menu row. EncodingRegistry.OfferedEncodings is now the one list, and it documents the invariants both UIs depend on (resolvable by its own header name, no two entries sharing a code page, append rather than sort). Adding an encoding is a one-line change there. The menu rows are built from it at runtime by EncodingMenuBuilder rather than declared one by one in the designer. Each row carries the Encoding it stands for in its Tag, so the click handler applies whatever the clicked row carries (one handler, was five) and the check-state lookup compares against it (was a cascade naming every encoding). Rows are labelled with their header name, the same text the combo box shows, which retires five resource keys that were dead anyway - the constructor overwrote them before anyone saw them. Also fixes what GB2312 exposed in the legacy and XML readers, which advance their position per character by a per-encoding step: GetPosIncPrecomputed credited every encoding that is not UTF-8 or UTF-16 with one byte per character. GB2312 is the first offered encoding that is neither single-byte nor Unicode, so the position drifted on the first Chinese character and every later line began at the wrong offset. The step is now keyed on Encoding.IsSingleByte, and 0 ("measure the character") covers the variable-width case. Test coverage follows the seam: the list invariants are asserted once against the registry instead of per dialog, and the menu fixture is filled by the real builder, so it can no longer describe a menu the application does not build. | 1 个月前 |