wzn
Newbie | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Всё было бы замечательно, но в Unit1 уже есть uses unit2. И при добавлении встречной команды - ругается. Однако, пока ждал ответа, обнаружил что если прописать в UNIT2 инспекторе объектов встречно (MasterSource Form1:... ) то компилирует, хотя по прежнему не дает реакции после точки по тексту на ссылки в первый UNIT1. Ну хоть в каждой форме файлы открывать заново! Вообще всё должно функционировать одним модулем UNIT1. Единственное окно без коррекции базы - толко обработка событий и звонок в означеное время, типа шедулера. А правка может вообще не с этой машины идти. Так что Unit2 - рудимент. И нужен только для отладки. Вот он и должен использовать написаное в UNIT1 по максимуму. Там открытие, работа, а в модуле 2 только процедуры-паразиты. То есть уходя/запуская UNIT2 (экранную форму) я должен присосаться к уже открытым записям модуля1, поправить их "по ходу" и свалить, возможно с коррекцией базы. Модуль1 только читающим был задуман, но это не принципиально. По ходу возник еще вопрос, если индексируем (один файл индексов) по 2-м,3-м полям, то как это написать? Dbf1.AddIndex('По_полю1','Pole1',[ixPrimary,ixUnique]); а куда воткнуть 'Pole2','Pole3'? Отсортировать в UNIT2 по 3-м полям, показать там-же, переписать базу из пары десятков значений не на долго заблокировар от UNIT1 файлы и свалить удалив файл индексов (он нужен только в UNIT2!) При этом UNIT1 работает (должен работать) толко с одним DBF, даже не пытаясь ломиться в индексы. Такое возможно? ps. Lazarus IDE 1.1 (может в версии дело?). {$H+} ps2. Прежние вопросы по прежнему актуальны. Особенно о черном ящике и моменте чтения/преобразование считанного DOS-текста из базы и попадания его уже разпухшим в UTF8 строки экрана (или таблицах памяти). Как же достал этот UTF8! Где: Поле_таблицы := CP866toUTF8(Поле_DBF); // При этом поле таблицы должно быть 2x поля DBF по длине (asString) и где обратно преобразуется? В каком месте/свойстве/событии прописывать и что прописывать? Как объяснить Лазарусу, что строки в памяти должны быть длиннее строк базы в 2 раза(!) минимум? Нужно нечто, позволяющее решить эту проблему единовременно. Чтоб после просто файлы кидать в проект и не думать об их длине и не возиться с каждым полем в отдельности. А если DBF будут с разными кодировками? Страшно даже подумать! Правда, UTF8 не предвидится в любом случае, а вот гемор при обработке обеспечен. Мне не нужны в базе (файле DBF) поля двойного размера. Надеюсь, использовать метод в дальнейшем. Понятно, что для десятка записей не принципиально. Я ищу метод. Хорошо бы самый правильный с точки зрения Lazarus. Пока что Lazarus пытается эти поля сделать одинаковыми. ps3. Разработка на W7, а вот работать должно на V7,XP как минимум. А Lazarus 1.2 сильно отличается с точки зрения работы с DBF? Может там такие проблемы уже решены? | Всего записей: 10 | Зарегистр. 11-11-2008 | Отправлено: 13:15 13-11-2014 | Исправлено: wzn, 13:57 13-11-2014 |
|