nouyana писал(а):Вообщем, если вы имеете в виду какой-то конкретный пример из этой "кучи", то назовите его, пожалуйста.
Что бы найти, какой либо пример, то эту "кучу" надо иметь, а у меня в данный момент этой кучи нет. Это во первых, а во вторых могу ответственно заявить, что примеры, которые идут в дополнение к хелпу не предназначены для использования по принципу "как есть", т.е. взял скопировал и все, а предназначены для изучения отдельных моментов в довесок к документации. Что бы получилось что то внятное, нужно сначала внимательно изучить предлагаемую гридом объектную модель (для всех составляющих объектов), в процессе изучения, нужно будет читать документацию и обращаться к примерам. Это в общем.
А в частности, по тому примеру, который приведен в топике выше:
Получить искомое (удобочитаемый вид с заменой вторичных ключей на значения) можно кучей способов:
Способ - 1:
Использовать только возможности самого грида и его коллекции ValueItems. Для этого нужно программным способом её заполнить, соответствующими ключам значениями и установить флаг трансляции. Тогда вместо значений ключей, в полях грида будут отображаться соответствующие ключам наименования.
Плюсы этого способа: простота и удобство. Написал класс, на стадии инициализации подключил его к гриду и вуаля. Если изначально продумать систему наименований для таблиц и полей базы данных, то можно вообще все автоматизировать. Я бы сделал так (один из множества вариантов): Всем полям с первичным ключом присваивал имя ID, а вторичным ключам комбинацию названия таблицы и "ID". При таком раскладе можно получить ссылку на рекордсет, обойти его поля, и выявляя поля вторичных ключей по динамическим свойствам получать имена таблиц из названия поля, и далее генерируя соответствующий запрос и получая данные, заполнять коллекцию ValueItems для каждого связанного с полем вторичного ключа столбца.
Минусы этого способа: низкая производительность. Если таких столбцов будет много, а списки трансляции будут большими, тогда заполнение может начать тормозить. Но у этого способа есть куча методов для существенной оптимизации. Все зависит от того, где и как этот метод планируется применять.
Способ - 2: Использовать объект TDBDropDown. В этом случае, на каждый столбец будет приходится по одному такому объекту (в общем случае). К каждому экземпляру TDBDropDown нужно будет подключить свой рекордсет с данными для трансляции. У этого способа тоже валом подвариантов использования. Например изначально можно кидать на форму один грид и один TDBDropDown, оформленный как элемент массива, и далее при инициализации или при смене источника данных, программно (по принципу из 1 способа) множить экземпляры TDBDropDown, подключать их к соответствующим полям и автоматически генерирую запросы подключать соответствующие рекордсеты.
Для этих способов также важно предусмотреть случаи изменения списков трансляции, при изменении/добавлении/удалении записей в первичных таблицах базы данных.
Я описал самые простые из возможных способов и применительно с использованием ADODB (для DAO тоже можно будет аналогично).
. То есть:
.
) Короче, инкапсуляция - это тема,