|
|
|
CP866 Grid
|
|||
|---|---|---|---|
|
#18+
Мне надо применять Visual Fox 9 с базой данных в свободных таблицах в кодировке CP866. Задача осложнена использованием искуственных ключей по полям Character, в которых есть двоично нулевые начальные символы (DOS-аналог Character Binary). Команды SEEK и SET RELATION в сеансе с CONFIG.FPW!CODEPAGE=1251 по таким полям не работают независимо от SET NOCPTRANS. Как обеспечить визуальное проектирование форм с Grid.RecordSourceType = Table или Alias с "прямым" доступом к таблицам данных, не прибегая к выборке в курсор? Мой опробованный подход не очень удобен. Разработка ведётся с CONFIG.FPW!CODEPAGE=1251. В контролах для правки таблиц используется шрифт CP866 и ON KEY LABEL для перекодировки клавишных посылок из 1251 в 866. Запуск приложения с CONFIG.FPW!CODEPAGE=866. При этом приходится все отображаемые на форме текстовые литералы в контролах (например, Caption) перекодировать в Object.Init из CP866 в CP1251, т.к. среда выполнения при запуске приложения без спроса переводит литералы из CP1251 в CP866. Хотелось бы найти в Grid такой метод-событие, в котором можно было бы перехватить загрузку Column.TexBox.Value значением из таблицы и выгрузку его обратно в таблицу. Методы Value_Assign и Value_Access не годятся, т.к. данные изменения TextBox.Value Grid делает "за кулисами", не вызывая _Assign/_Access. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2005, 14:44:04 |
|
||
|
CP866 Grid
|
|||
|---|---|---|---|
|
#18+
Сранно, что NOCPTRANS не помогает, мне как-то пришлось иметь дело с таблицей от FPD в 866 кодировке с зашифрованными полями типа Char, в которой при шифровании использовались символы псевдографики и прочие. Насчет Relation ничего не могу сказать, а вот Seek работал абсолютно без проблем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2005, 15:43:14 |
|
||
|
CP866 Grid
|
|||
|---|---|---|---|
|
#18+
WORKSNS. А ты вспомни, что у тебя было в CONFIG.FPW!CODEPAGE. В этом суть. Работает только при CONFIG.FPW!CODEPAGE=866. Ты не врубился в ситуацию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2005, 18:08:41 |
|
||
|
CP866 Grid
|
|||
|---|---|---|---|
|
#18+
Да нет, сейчас только глянул - codepage=1251 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2005, 04:51:40 |
|
||
|
CP866 Grid
|
|||
|---|---|---|---|
|
#18+
У Вас неверное представление о работе FoxPro с кодовыми страницами. Настройка CODEPAGE=... в файле конфигурации выполняет 2 функции: Включается сам факт автоматической трансляции (конвертации) разных кодовых страниц В качестве текущей кодовой страницы среды FoxPro устанавливается указанная после равенства кодовая страница. Если указать NOCPTRANS для ряда полей открытой таблицы, то это означает, что эти данные не надо транслировать (конвертировать). Их следует восприниамть "как есть", т.е. как созданные в текущей кодовой странице FoxPro. Т.е., если у Вашей таблицы явно прописан признак кодовой страницы (CPDBF()=866), и в файле конфигурации указано CODEPAGE=1251, то данные из этой таблицы будут автоматически траслироваться из кодовой страницы 866 в кодовую страницу 1251. Если же наложить ограничение NOCPTRANS, то данные из этих полей транслироваться не будут и будут восприниматься как созданные в кодовой странице 1251. Теперь, что имеем с индексами (SEEK и RELATION) Индексный файл - это отдельный (другой) файл. Приблизительно, содержимое индексного файла - это пары: значение ключа - идентификатор записи. В данном случае, нас интересует то, как именно записано это самое значение ключа. В какой кодовой странице. Точнее так, как связана кодовая страница собственно файла DBF и кодовая страница, в которой записано значение ключа в индексном файле. Вот фрагмент объяснения Алексея Цингауза (представитель MSFT - разработчик FoxPro) Алексей ЦингаузПри построении идекса нужно учитывать следующую деталь. Когда индексное выражение вычисляется, значения полей читаются с диска как есть, без трансляции в текущую кодовою страницу. А вот многие функции оперируют по разному, в зависимости от текущей кодовой страницы. UPPER один из примеров такой функции. Если текущая кодовая страница 1251 а кодовая страница таблицы 866, то к букве "а" в кодировке 866 UPPER применит кодовую страницу 1251. Естественно, буквы "А" в кодировке 866 не получится. Если планируется строить индексы или модифицировать данные под разными текущими кодовыми страницами, то индексное выражение должно быть инвариантно отностельно текущей кодовой страницы. Всю дискуссию полностью по этому вопросу можешь почитать здесь http://forum.foxclub.ru/read.php?f=29&i=325&t=307 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2005, 15:04:50 |
|
||
|
CP866 Grid
|
|||
|---|---|---|---|
|
#18+
Для WORKSNS - не знаю, что сказать. У меня не так! Для Владимира М. Спасибо за подробные объяснения. Я действительно не всё разобрал в CPCURRENT - для чего аргументы 1 или 2. Ещё хуже с CP в DLL COM-серверах - там у меня вообще 1252. Но как мое непонимание сказывается на результатах такого простого кода? Они не согласуются с приведённой Вами теорией. В чем моя ошибка? Если не трудно, намекните, пожалуйста. * DMake866.PRG in FPD 2.6 WITH CONFIG.FP!CODEPAGE=866 SET TALK OFF SET SAFETY OFF CREATE TABLE D866; (HEX C (2); ,DEC N (3); ) FOR m.i = 0 TO 255 INSERT INTO D866 (HEX, DEC); VALUES (CHR(0)+CHR(m.i), m.i) ENDFOR INDEX ON HEX TAG HEX INDEX ON DEC TAG DEC ADDITIVE * Tst866.PRG WITH CONFIG.FPW!CODEPAGE=1251 * Run on VFP9 under WinXP-rus with SP2 SET TALK OFF CLOSE DATABASES USE D866 IN 0 AGAIN ALIAS A1 USE D866 IN 0 AGAIN ALIAS B2 SELECT B2 SET NOCPTRANS TO HEX SET ORDER TO HEX SELECT A1 SET NOCPTRANS TO HEX SET ORDER TO DEC SET EXACT ON && of no matter SET RELATION TO HEX INTO B2 COUNT TO m.k1 FOR DEC != ASC (RIGHT (HEX, 1)) COUNT TO m.k2 FOR A1.DEC != B2.DEC WAIT STR (m.k1, 4) + STR (m.k2, 4) WINDOW && Shows 0 128 BROWSE FIELDS DEC, H1 = STR (ASC (RIGHT (HEX, 1))); ,B2.DEC, H2 = STR (ASC (RIGHT (B2.HEX, 1))); FOR A1.DEC != B2.DEC ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2005, 11:07:31 |
|
||
|
CP866 Grid
|
|||
|---|---|---|---|
|
#18+
Hi Rostislav! Поищи в форуме на foxclub.ru - была довольно большая дискуссия про использование таблиц с "неродной" CP в VFP - речь шла про индексы с UPPER() - но оно касается на самом деле и простых индексов. То что ты "отменил" конвертацию для поля - НИКАК не повлияло на индекс. А в свою очередь использование такого "неродного" индекса и приводит к описанному результату. Единственное утешение - это то что при выполнении SQL запросов в 9-ке отключается оптимизатор - "неродные" индексы не используются - и результат является ПРАВИЛЬНЫМ. Например попробуй для своей тестовой таблицы выполнить такой запрос (ессно что предварительно установив NOCPTRANS на поле hex): SELECT * FROM d866 a1 INNER JOIN d866 a2 ON a1.hex=a2.hex Получишь вполне корректный результат - 256 элементов. В VFP7/8 (и наверное во всех прочих более старых) из-за использования оптимизатором неродного индекса мы ошибочно получаем только 128 элементов (первые 128 записей - для них коды символов что в 1251 что в 866 одинаковы). Т.е. В принципе МОЖНО работать из 9-ки с FPD таблицами, НО не пользовать нигде индексы (а значит и SET RELATION) - ни напрямую, ни косвенно (т.е. для оптимизации). стати в SP1 "по просьбам трудящихся" будет включена возможность старой КРИВОЙ работы движка - конечно при SET ENGINEBEHAVIOUR < 90 - т.е. у "жалобщиков" появится выбор - работать НЕПРАВИЛЬНО но быстро, или ПРАВИЛЬНО но медленно. Впрочем для англичан "неправильность" не должна сказываться - если они конечно не пользуют ИМЕННО hex поля - а только строковые поля со своими английскими буковками (128 элементов из "нижней" части таблицы символов). Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2005, 03:03:21 |
|
||
|
CP866 Grid
|
|||
|---|---|---|---|
|
#18+
Igor Korolyov, спасибо. Я так понял, поиски принципиального решения можно оставить. Если ты следил за моими вариантами темы CP866 ..., я опробовал два обходных решения. 1) Правка в Grid через Control с Font на CP866 и перехватом/перекодировкой клавишных посылок для Control из 1251 в 866. 2) Показ CPCONVERT (866, 1251, Data) через Control1 и правка/валидация через Control2, вывешиваемый на Form когда надо поверх Grid.Control1. Пришёл к мысли: способ 1 легче. По способу 2 слишком много возни с отключением (LostFocus) Control2 при навигации, Resize/Move для Column/Rows и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2005, 23:21:33 |
|
||
|
|
start [/forum/topic.php?fid=41&fpage=292&tid=1593066]: |
0ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
17ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
| others: | 234ms |
| total: | 345ms |
| 0 / 0 |
