В текстовых документах русские буквы при вводе отображаются неправильно. В текстовом файле - русский алфавит, набранный в 1с8 (Аа Бб Вв ... Яя)
В 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
