| Summary: | Не вводятся русские символы в 1с8 | ||
|---|---|---|---|
| Product: | WINE@Etersoft | Reporter: | Константин Кондратюк <kondratyuk> |
| Component: | Обработка текста и локали; Буфер | Assignee: | Константин Кондратюк <kondratyuk> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P5 | CC: | baraka, lav |
| Version: | 1.0.5 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Заявки RT: | Связано с: | ||
| Дата напоминания: | |||
| Bug Depends on: | |||
| Bug Blocks: | 437, 287, 855, 7435, 7489 | ||
| Attachments: | Текстовый файл, созданный в 1с8 | ||
|
Description
Константин Кондратюк
2006-12-27 13:44:57 MSK
В 1с 8.1 проблема та же Разберусь. С перекодировкой в ср1251 всё нормально. Н-да... Кость, ну надо писать примерно так: Это связано с тем, что 1C 8.0 определяет на какой платформе запущена и в дальнейшем использует функции DispatchMessageA, GetMessageA и пр. A для не-NT платформы, и соотв. функции W (юникодные) для NT-платформ. В какой-то момент введённый с клавиатуры юникодный символ (например 0x442) преобразуется отсечением старших байт в однобайтовый (0x42), без перекодирования. Возможно это связано с тем, что где-то программа ожидает 8-мибитный символ, а получает WCHAR. Он ей не нравится и она использует его как char... Да, забыл сказать - есть такая программа FileWorkShopRU.exe (по сути это просмотрщик файлов 1С 7.7/8.0), в которой проявляются все глюки с платформой 1С. Она находится в бутылке 1cfile, на ней можно отлаживать задержку в меню, калькулятор, редактирование... И не нужно мучаться от разных защит. Кстати, программа "распространяется свободно". Над темой кодировок работает Толя. Не забыть дописать в комментарии что функция SetLong*W ведёт себя как SetLong*A в опред. случаях. Проблема ввода для 1с8 решена. Патч приложен. Дело в том, что при версии win98 в вайне создаётся неюникодное окно, а обработчик на него вешается юникодный (похоже, это только у 1с проявляется). Нужно написать тест для этого случая перед отправкой патча. Тест показал, что windows позволяет программе менять статус окна на юникодный, вешая на него другой обработчик. В этом wine и windows идентичны. Неправильно отключать возможность присвоения юникодного обработчика неюникодному окну в вайне. Проблема с обрезанием байта кода символа где-то в дальнейшем вызове функций. Расширяем тест для диагностики этой ошибки... Патч, исправляющий ввод в 1с8 пока оставляем, но его нужно заменить на более правильный вариант. Варианта проблемы два: 1. Окно делается юникодным, когда ему присваивают юникодный обработчик. После этого по каким-то причинам, wine всё равно работает с ним как с неюникодным. В этом случае нужно разобраться, где происходит подмена функций. 2. Окно в win98 должно быть неюникодным. В результате какой-то ошибки на него вешается юникодный обработчик. Тогда нужно понять, почему вызывается SetLongWindowW в режиме win98. Наиболее вероятным видится второй вариант. Патч исключаю из сборки, т.к. он портит работу других функций (проблема с отображением полей при клике стрелочками updown, например). Ищем другой способ решения. Хак, обрабатывающий установку обработчика для окна класса "V8Window", прикладываю к сборке 1.0.6. Нужно потестировать на стабильность ввода в другие окна (скорее всего только 1с8, т.к. класс с именем V8Window встретишь не часто) Исправлено для 1.0.6 |