Редактор видимості полів гріду своїми руками, Різне, Програмування, статті

Автор: 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>

*

*