TStringGrid и скрытые колонки

[krab]

Есть TStringGrid с 2-мя колонками, у второй из них Visible = False.
При выполнении

Код: Выделить всё

StringGrid1.Rows[0].Strings[1]:='sdsd';

возникает ошибка

Код: Выделить всё

exception class 'EGridException' with message: Index Out of range Cell[Col=1 Row=0]

Можно ли как-то писать и читать скрытые колонки у TStringGrid? Как это делается?

[Vladimir_Ivanov]

Ну, вообще то таблица нужно чтобы данные отображать, а не хранить. По этому создайте ну скажем список (TList) с указанием на выши данные скорее всего это ваш класс, и меняйте данные наздоровья, можно для каждого экземпляра класса добавить свойство Visible. Или непосредственно читать свойства таблицы и отображать данные в нее. Скажем пользователь изменил данные то обновите таблицу, если же пользователь изменил данные именно в таблице (текстовые) то их сохраните в указатель на класс из списка TList. Потом хоть таблицу всю спрячте или даже удалите, данные остануться в твоем списке. Хотя как всегда я могу очень сильно ошибаться....

[AbakAngelSoft]

Хотя как всегда я могу очень сильно ошибаться....

Не ошибаетесь - данные всегда необходимо отделять от представления.
Мухи отдельно - котлеты отдельно. Иначе никак.

[alexmai]

Есть TStringGrid с 2-мя колонками, у второй из них Visible = False.
При выполнении

Код: Выделить всё

StringGrid1.Rows[0].Strings[1]:='sdsd';

возникает ошибка

Код: Выделить всё

exception class 'EGridException' with message: Index Out of range Cell[Col=1 Row=0]

Можно ли как-то писать и читать скрытые колонки у TStringGrid? Как это делается?

Да я просто ширину колонки ставил нулевую

Код: Выделить всё

MyStrinGrid.ColWidths[0]:=0;


[eevee]

угу, я также ))) решение всех проблем )

[AbakAngelSoft]

решение всех проблем )

Это не решение проблем, а создание отличного задела для проблем в будущем.

[Logo]

решение всех проблем )

Это не решение проблем, а создание отличного задела для проблем в будущем.

100%

Можно ли как-то писать и читать скрытые колонки у TStringGrid? Как это делается?

Нельзя, потому, что оно не работает. Это непоправленный БАГ!

[krab]

Не ошибаетесь - данные всегда необходимо отделять от представления.
Мухи отдельно - котлеты отдельно. Иначе никак.

А если данные грузятся туда из БД, которая по сути и есть "данные"? Получается дублирование. Просто делать запросы на каждый чих долго и неудобно, проще брать их из грида, например.

P. S. Да, я не пользуюсь dataset и database-aware компонентами для вывода данных(TDBGrid и т. п.).

[Padre_Mortius]

делать запросы на каждый чих

в разы удобнее нежели руками формировать необходимый функционал. Пример, сортировка по полю. Допустим записей около 1000. Что быстрее отработает скульный запрос или ваша реализация с чтением и сортировкой записей?

[AbakAngelSoft]

А если данные грузятся туда из БД, которая по сути и есть "данные"? Получается дублирование. Просто делать запросы на каждый чих долго и неудобно, проще брать их из грида, например.

Просто разработчики vcl, в свое время, пошли на угоду "кликальшикам" для увеличения популярности своего продукта - поэтому данные и можно хранить в гриде. Однако это не значит что "правильные" программисты должны поступать именно так.
По хорошему, для хранения данных в программе должен применяться объект с промежуточными данными, а может и несколько объектов реализующих различные аспекты поведения (хранение, сортировка, выборка) а грид используемый только для отображения, должен взаимодействовать с некоторым агрегатором этих объектов через единый определенный интерфейс - никакого дублирования и очень легкая поддержка кода.

[FedeX]

Писал в баг трекер про этот баг ещё пол года назад.. Видно так и не поправили. Возможно из соображений как у AbakAngelSoft с коими согласен на 100%. Как промежуточный вариант можно хранить данные по каждой записи в каких-нибудь обьектах. Каждому полю грида назначать соответствующий обьект (Grid.rovs[0].objects[0]:=new_record; как-то так не помню) и отрисовывать грид самостоятельно (это не очень сложно и всё-равно почти всегда необходимо). Так и данные не будут дублироваться в памяти и модель MVC будет (хоть и частично) соблюдаться, что весьма упростит поддержку кода. Вообщем пол-года назад я так и поступил..

Padre_Mortius
Выборки-то он как я понял использует, не использует только дбгриды с соурсами.

[krab]

Например, в БД есть таблица Клиенты:
Client_Id, Client_Name, Client_FathersName, Client_FamilyName. Делается выборка по ней и заполняется грид.

Решение #1(не работающее из-за запрета на чтение скрытых полей):
Есть StringGrid с полями:
Client_Id(СКРЫТОЕ), Client_FullName(конкатенация соответствующих колонок из таблицы)

При нажатии на кнопку "Добавить заказ" из StringGrid берется Id клиента, по нему формируется запрос на добавление заказа.

Решение #2(предложенное здесь):
Есть StringGrid с полем:
Client_FullName

Есть динамический массив с полем:
Client_Id

При нажатии на кнопку "Добавить заказ" из StringGrid берется номер строки, по ней из массива берется Id клиента, по нему формируется запрос на добавление заказа.

Решение #3(запросы на каждый чих):
Есть StringGrid с полем:
Client_FullName

При нажатии на кнопку "Добавить заказ" из StringGrid берется Client_FullName, делается запрос в БД, чтобы найти клиента с таким именем и узнать его Id, после чего по Id формируется запрос на добавление заказа.



Вывод
Просто для ясности. Лучше всего Решение №1, немного хуже №2, №3 с запросами на каждый чих проигрывает другим во всем. Остановлюсь на №2. Насколько я понимаю, ничего лучше не найду.

Выборки-то он как я понял использует, не использует только дбгриды с соурсами.

Да. Там где есть смысл их использовать, выборки есть.

[and]

2krab: Ну, Вы ещё не упомянули решение №4: "Есть StringGrid с полями: Client_Id(нулевой ширины), Client_FullName(конкатенация соответствующих колонок из таблицы)".

[krab]

2krab: Ну, Вы ещё не упомянули решение №4: "Есть StringGrid с полями: Client_Id(нулевой ширины), Client_FullName(конкатенация соответствующих колонок из таблицы)".

Это вариация на тему решения №1. Есть опасения, что в следующей версии лазаруса такой хак может не сработать.

[Padre_Mortius]

Ну тогда подкину вам пример где поле ID желательно:
у вас есть два клиента Иванов Иван Иванович. Один заведен раньше, а другой позже. И вам нужно выбрать именно правильного клиента при заведении договора. Как вы их отличать будете?

А по поводу скрытия полей.. Никто вам не мешает заполнять DBGrid нужными полями (TColumns) при работе программы (настройка DBGrid может происходить при создании формы). Но работать нужно не с данными в DBGrid, а имено с данными в датасете и работайте с вашими невидимыми полями себе в удовольствие.