Здравствуйте, Алексей.
Заранее прошу прощения, если мое письмо заставило Вас оторваться от более важных дел!
Сразу оговорюсь — речь идет о версиях Clarion С5/C55.
Разбираясь с внутренней организацией структур типа GROUP/QUEUE/CLASS/FILE обратил внимание на некоторые особенности описания OVER-полей. Это, впрочем, касается только OVER-полей, размер которых МЕНЬШЕ перекрываемой ими структуры. В этом случае поле, следующее за таким OVER-полем, описывается также как OVER-поле.
Причем сдвиг для данного поля задается таким образом, что область перекрытия начинается с точки, равной Address(BaseField)+Size(OverField).
Естественно, что компилятором это дело игнорируется, так как он работает с непосредственной информацией о полях структуры. Но вот во всех остальных случаях, когда работа с полями таких структур ведется на основании описания полей, мы имеем не одно OVER-поле, как положено, а два и более (в зависимости от размера перекрываемой структуры).
Особенно наглядно это демонстрирует, например, TopScan! А браузер, встроенный в оболочку, как Вы очевидно знаете, вообще отказывается работать с файлами, имеющими в своей структуре такие поля!
Вот и хотелось бы узнать — это ошибка разработчиков или внутренняя особенность? И, если это не ошибка, то с какой целью это сделано? Дело в том, что я пробовал корректировать данное описание полей и все работает нормально! И драйверы (TPS/DAT) и TopScan нормально и правильно воспринимают скорректированную структуру.
А как Вы генерите описание подобной структуры в своей библиотеке xLib? Кстати, почему Вы в данной библиотеке не реализовали динамические View? Именно последнее и стало причиной разработки мною своей библиотеки DynaView. Что, естественно, потребовало более полного знания внутренней реализации всех основных структур Clarion`a.
Насчет View!
Известно ли разработчикам, что атрибут Inner, указанный непосредственно в описании View-структуры, работает для TPS-файлов? А вот переключение его с помощью {PROP:Inner,Join#}, видимо просто не обрабатывается ViewDriver`ом! Да и при попытке прочитать значение данного атрибута всегда получаем 0 (ноль). Те же проблемы и с JoinExpression. А свойство {PROP:JoinExpression,Join#} вообще возвращает всегда не строку, как положено, а число 0 (ноль)! Эти две странности, в частности, также явились причиной написания DynaView, которая позволяет эмулировать нормальное управление данными свойствами путем полной переинициализации View-обьекта с заменой адреса заголовка. Кстати, можно ли заставить ViewDriver заново перечитать описание структуры View без изменения адреса заголовка?
И, если Вы не против, еще несколько вопросов.
Почему указатель на группу ($GROUP) отличается от подобных указателей $QUEUE/$FILE, которые являются простыми указателями на соответствующие заголовки? Тогда как $GROUP сам представляет собой такой заголовок.
Зачем в заголовке каждой записи очереди — точка входа в PipeProc? Ведь всегда используется одна и та же. Правда, при сжатии используется другая PipeProc. Но ведь в пределах одной очереди возможны только однотипные записи!
Есть ли возможность подмены процедуры сравнения записей очереди, которая используется для сортировки и поиска по ключу? В основном, необходимо для реализации сортировки и поиска по полям типа &STRING. Как известно, в описании такие поля представлены как простые рефералы без указания типа, на который они указывают. И, естественно, PipeProc при сортировке обрабатывает их соответственно.
Когда, все-таки, ожидается выход 32bit C6? Или он уже будет 64bit, как упоминалось в интервью Боба Заунера, данного Clarion Magazine?
Вообщем, подобных вопросов очень много! Жаль что так мало подобной информации дано в документации и Help! АРСИС, к сожалению, в данном плане не помощник. Можно ли ожидать каких-либо изменений в этом плане?
Спасибо!
P.S. В связи с тем, что я не связан какими-либо обязательствами с фирмами TS/SV, я оставляю за собой право на предоставление полученной от Вас информации другим Clarion-программистам. Вы, тем не менее, имеете право запретить мне ссылаться на Вас, как источник информации.