Укажите отработанное время

Отработанное время:
Продуктивное время:
Bug 498 - 1Cv77: Ошибка при формировании полей dbf-файлов   Make a simular bug
Summary: 1Cv77: Ошибка при формировании полей dbf-файлов
Status: CLOSED FIXED
Alias: None
Product: WINE@Etersoft
Classification: Продукты (Products)
Component: Общее (show other bugs)
Version: 1.0.6
Hardware: PC Linux
: P5 major
Target Milestone: ---
Assignee: Анатолий Лютин
QA Contact:
URL:
Whiteboard:
Keywords:
: 863 (view as bug list)
Depends on:
Blocks: 760 42 584
  Show dependency treegraph
 
In work:
Reported: 2007-03-07 15:08 MSK by Vitaly Lipatov
Modified: 2008-09-25 02:24 MSD (History)
4 users (show)

See Also:
Заявки RT:
Связано с:
Дата напоминания:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vitaly Lipatov 2007-03-07 15:08:01 MSK
1. из 1с формируются dbf-файлы, в названии полей "u" меняется на "M" (?!?).
то есть в коде написано:
 Т=СоздатьОбъект("XBase");
 Т.ДобавитьПоле("Summa","N",10,2);
 Т.СоздатьФайл(ИмяКаталога+"DT_Rash");

создается файл с полем "SMMMA" (в dbf названия полей хранятся
заглавными буквами).

если переписать код на
 Т=СоздатьОбъект("XBase");
 Т.ДобавитьПоле("SUmma","N",10,2);
 Т.СоздатьФайл(ИмяКаталога+"DT_Rash");
всё отрабатывает нормально.
Comment 1 Анатолий Лютин 2007-03-12 18:38:14 MSK
Принимаю багу, прошёлся трейсами по all, пробовал класть 1с по вызову строчки "uuuuuuuuuu", ничего интересного трайсы не дают. Ставили mfc42.dll из поставки 1с - то же самое. В Вин всё нормально. Проблема только с маленькой буквой u, даже русские символы и то записываются правильно... Не всё так просто. 
Comment 2 Vitaly Lipatov 2007-11-07 13:43:17 MSK
*** Bug 863 has been marked as a duplicate of this bug. ***
Comment 3 Vitaly Lipatov 2007-11-07 13:44:21 MSK
При указании кодировки windows -
ДБФ.КодоваяСтраница(0) все ок, проблема
возникает с кодировкой по умолчанию dos -
ДБФ.КодоваяСтраница(1)
Comment 4 Vitaly Lipatov 2007-11-29 23:52:12 MSK
По-английски функция называется AddField.
Элементарный toupper из msvcrt используется для поднятия типа поля к верхнему регистру.
Так же возможны MakeUpper из Type32 или Lower2Upper из BkEnd.
CharUpperA и
CharToOemA, CharToOemBuffA (раз проблема только при использовании Кодовой страницы DOS).
Comment 5 Vitaly Lipatov 2007-12-03 23:05:28 MSK
Lower2Upper из bkend.dll реализована на основе собственной таблицы, по которой символы просто приводятся к верхнему регистру. Таблица формируется на основе CharUpperA, причём Lower2Upper является часто используемой функцией, и проблем от неё ожидать не приходится.

MakeUpper из type32.dll является просто обёрткой для CharUpperA, работающей с принятыми в 1С строками.

Comment 6 Vitaly Lipatov 2007-12-04 00:33:28 MSK
CharToOemBuffA преобразует букву микрон (0xB5) в u (0x75),
в то время как в Windows получается 0xE7.
Поскольку CharToOemBuffA использует
        MultiByteToWideChar( CP_ACP, 0, s, len, bufW, len );
        WideCharToMultiByte( CP_OEMCP, 0, bufW, len, d, len, NULL, NULL );
нужно серьёзно разобраться, правильно ли они работают.

Причём странно, что символы поступают на сравнение так:
B2
A5
B5 (вредная B5)
4D (злосчастная M!) - причём имеет другой выходной буфер, то есть не в этом цикле вызывается.
A8
AA
Как это получается, не ясно...

А, передаются пары - маленькая-большая, т.е.
a
A
b
B

из этой микрон получается
u
следом за которой её вариант микрона - M.


То есть нельзя, чтобы CharToOemBuff создавал буквы, которые уже были.


Временно приложен патч hack/lstr.c.patch

Comment 7 Анатолий Лютин 2007-12-04 21:53:30 MSK
Написал патч lib-fixoem.patch, который должен решать эту проблему корректно. Хак отложил.