Редактор видимості полів гриду своїми руками

Автор: voldan, Королівство Delphi


Сьогодні хотілося б запропонувати Вам на обговорення досить цікаву тему під назвою "Можливість редагувати видимість полів гриду", що відповідає всього-лише двом умовам: мабуть (Visible = True) та приховано (Visible = False). І до даної теми додаю власний компонент TFldSetting, який здатний прискорити ту рутину, з якою нам всім доводиться зустрічатися. Звичайно ж, багато програмісти мають у своєму арсеналі щось подібне, розроблений ними ж або сторонніми розробниками. Але як же бути починаючому програмістові або програмісту, який не замислювався про можливість надавати користувачеві (Для якого і пишеться, власне, додаток) можливість додавати-видаляти колонки гріду? Адже він теж хоче якісне застосування, здатне задовольнити як і замовника, так і самого програміста. Одужаю, додавати-видаляти колонки – це дія (ілюзія) з боку користувача, а з боку програміста, звичайно ж, це просто виробляти "редагування видимості полів сітки", тобто просто приховувати і показувати ці поля, не більше того.


Трохи про історію назви компонента "Редактор видимості полів". Справа в тому, що я довго думав, як же краще російськими словами можна охарактеризувати даний компонент. Були ідеї назвати його "Бачимо-невидимий", "Невидимка", "Дещо ще про видимість":, але все це якось не особливо в'язалося мовою. І одного ранку, прийшовши на роботу, мене осяяло: "Редактор видимості полів гриду"! Це чудове назву повалило в шок певних працівників, коли я у них запитав: "Як вам такий варіант редактора видимості полів гриду"? 🙂 Вони запитали, що, Дань, знову че-та вигадуєш? А я кажу: "Та ні ж! Це звичайний "Редактор видимості полів гриду"! Ось так і з'явилося це чудове назва:)


У кожної сітки (майже у кожній) є властивість Columns, яке відкриває нам доступ до об'єктів-стовпцях класу TColumn. Чому я сказав майже у кожної, тому що є деякі сітки (наприклад, TcxGrid, грід, який входить в комплектацію бібліотеки DevExpress), у яких доступ до стовпцях здійснюється трохи по-іншому. Сторонні компоненти в даній статті я розглядати не буду, тому що орієнтуюся на більшість як початківців програмістів, так і досвідчених гуру, які користуються стандартними компонентами. Хочу видужати, деякі сторонні компоненти (наприклад, TDBGridEh з бібліотеки EhLib) мають багато спільного зі стандартним TDBGrid, що в 100-процентному випадку підходить для роботи з даним компонентом. На самом деле, я сам працюю виключно з TDBGridEh, і в самому початку компонент був "заточений" саме під нього. Довелося для вас трохи модернізувати компонент, щоб він працював під стандартним TDBGrid. Повірте, нічого тут складного немає, якщо хтось захоче перевести роботу компоненту під інші сітки. Природно, якщо захочеться, можна пристосувати роботу компоненту до різних гріди методом "простого перерахування", але, щоб не ускладнювати код зайвими модифікаціями, я вирішив не цю дію.


Але це все стосується самого гріду. Багато товаришів працюють напосредственная з наборами даних, додаючи і видаляючи поля, привласнюючи їм назви, імена, проставляючи видимість і так далі. Даний компонент до таким товаришам не відноситься, тому що він працює виключно за колумнеї гріду. Справа ось в чому. Програміст, залівшій поля в сам набір, позбавляється чудової можливості використати цікаві речі об'єктів-стовпців. Я в цій статті не буду обговорювати, що краще, а що гірше, це ми зможемо обговорити і на форумі, але скажу одне – до пори до часу я і сам користувався заливкою полів в сам набір даних, але дуже втрачав в іншому. Я вже говорив, що користуюся TDBGridEh, так от, можливості стовпців у даному гріді набагато перевершують можливості стандартного TDBGrid. Знову ж таки, перераховувати їх не буду, кому цікаво, можуть самі оцінити.


Якщо програма розробляється для одного користувача, то, за великим рахунком, програміст може один раз настроїти видимість полів і забути про це. Але існують серйозні програми, з якими доводиться працювати безлічі користувачів, у яких є свої права доступу, певні привілеї по роботі з даними і так далі. І кожному такому користувачу необхідно бачити, підкреслюю, СВОЇ "колонки даних ". Наприклад, одному користувачеві необхідно бачити в довіднику співробітників" Пол співробітника ", а інакше це абсолютно не важливо. Так давайте дамо можливість користувачам самим вирішувати, що вони хочуть бачити, а що ні?


Для початку, давайте визначимося зі специфікою завдання.


  1. При певному подію відбувається виклик форми компонента, в якій перераховуються поля гріду.
  2. Користувач методом установки прапорця в чекбокса (працюємо з TCheckListBox) налаштовує видимість полів
  3. При натисканні на кнопку "Зберегти" настройки зберігаються, а при натисканні "Скасувати" – відбувається відкат всього того, що було виставлено.

Ось, в принципі, і все бабусині огірочки, як я люблю говорити:)

А тепер давайте зануримося в деталі, з якими нам належить розібратися.

Якщо програміст захотів не світити поле (я) в редакторі, а в гріді світити, він проставляє в об'єкта-стовпця Tag = -1. Ви скажіть: Такого властивості немає у стовпця TDBGrid! І будуть праві. Це властивість є у TDBGridEh "го стовпця. Тому, я в компоненті закомментаріл обробку невидимих у редакторі полів. Хто хоче працювати з TDBGridEh, на що, власне, компонент і претендує – міняємо всі оголошення змінних з TDBGrid на TDBGridEh і замість DbGrids.pas підключаємо DbGridEh.pas. Всього-то ділов. Так, і не забуваємо раскомментаріть обробку. Можна передбачити дану обробку і до звичайного стовпцю, але у нього нестолько мало властивостей, що не до чого навіть прив'язатися.


І так, про деталі ми теж поговорили. Давайте, тепер, познайомимося ближче з нашим компонентом і його можливостями.


Основна робоча навантаження лежить в модулі форми (той самий "редактор видимості"). Я вирішив не вантажити сам компонент, а, як прийнято вважати "хорошим тоном", вантажити сам модуль форми, щоб ця форма була самодостатньою і незалежною ні від кого. Тобто всю чорну роботу виконує саме її модуль, а сам компонент є, так би мовити, прокладкою між редактором і кінцевим розробником. Розробник задає компоненту необхідні вхідні дані, компонент ці дані передає модулю форми, модуль форми виробляє роботу і на виході ми отримуємо необхідний результат. Ось саме так і є робота.


Тепер про властивості і методи:


Є 4 основні властивості:


  1. Grid – Без коментарів
  2. IniFile – Повний шлях з ім'ям файлу *. ini, куди записується вся інформація по поточних настройок всіх датасетов програми, з якими оперує наш компонент.
  3. Mode: TMenuMode = (fAutomatic, fManual);
    fAutomatic – автоматичний режим компонента
    fManual – ручний режим компонента
  4. ShortCut – Комбінація клавіш для виклику редактора

Є 2 методи:


  1. GetFieldsSettings – Завантаження налаштувань полів з ini-файлу
  2. ShowFieldsSettingForm – Показ форми для налаштувань полів


Про режим fAutomatic.
Передбачається, що до виклику (включно) події OnShow форми (на якій лежить грід), необхідний датасет вже відкритий. Відбувається підміна цього обробника OnShow на новий з збереженням старого в змінну FOldShow: TNotifyEvent. І тільки при виклику деструктора нашого компонента старий обробник повертається формі. Насправді Ви можете сміливо налаштувати так, як буде зручно, щоб обробник повертався за інших умов і обставин, або взагалі не повертався, або взагалі прибрати автоматичний режим компонента. Це все залежить від конкретної специфіки робота програміста, його засад і звички, від його професіоналізму та досвіду. Особисто я (в основному, тому що завдання бувають різні) динамічно відкриваю необхідні датасети за подією OnShow даної форми. Деякі налаштовують активними датасети в Design Time (що вважаю абсолютно неправильним підходом). Але це не важливо, тому що даний матеріал написаний не для того, щоб вчити хорошого тону програмування (цьому можна повчитися на просторах Королівського форуму), а запропонувати одну з реалізацій настройки призначеного для користувача інтерфейсу. При цьому режимі, ще підміняється обробник форми OnKeyDown, куди, власне, і прописується ShortCut.

Про режим fManual:
Програмісту необхідно самому піклуватися про завантаження налаштувань полів з ini-файлу. Дана дія потрібно здійснювати через метод GetFieldsSettings. А показ редактора самому викликати за методом ShowFieldsSettingForm

У принципі, все необхідне я висвітлив у цій невеликій статті, інше Ви зможете дізнатися, заглянувши в надра самого компонента, а точніше в надра самого модуля редактора, так як він у нас самий напханий.


Компонент і приклад роботи додається.


  1. Компонент: модуль TFldSet.pas
  2. Форма: модулі: FieldsSettingFrm.pas і FieldsSettingFrm.dfm
  3. Проект: Test
  4. База employee.db

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*