Тестируйте...

Так, еще один StrGrider.

nesco, ты что-то перепутал... StringGrid был только один... Это не StrTable!

Amper, нет, это ты или перепутал, или забыл, их два и один из них не рабочий.
можно подумать ты мне Америку открыл. Я занимался разработкой нового XLStrGrid'a (целый топик по этому есть), но пока забросил, из-за неясной концепции отображения и хранения сателитных контролов.

А... Меня просто долгий период не было и я всё пропустил ))

Вот так давно это было!!! так что можно говорить заного. Всё равно ничего не изменилось.
Зря nesco, так опрометчиво отнёсся. Порт неплохой для реализации напильником (к сожалению автор порта не известен)
Но пошоркая слегка начальничком результат есть. (хотя это уже третья попытка портировать нормальную сетку)
Что собственно нужно:
1) Настраиваемый дизайн. + (есть всё что нужно, ведь это порт StringGrid со всеми вытекающими)
2) Multiline режим. (Реализовал. поучилось.)
3) Редактирование. (вообще без проблем встроилось.)

p.s кто включится в разработку предоставлю наработки

демка https://forum.hiasm.com/getfile/39276



Редактировалось 1 раз(а), последний 2021-08-27 18:33:14

Выглядит красиво.

При разработке не возникало неудобств с необходимостью хранить данные в самой таблице?
Не приходила в голову концепция разделить хранение/обработку данных в памяти и их отображение/редактирование пользователем в окне?

Таким образом возникает два набора компонентов:
- dataset или VirtualTable (отдельным компонентом; поключаемыми к нему компонентами данных, типа БД; содержащимся в других компонентах, тех же БД). Плюс компоненты работы с датасетом внутри схемы - работа со строками, колонками, значениями (ячейками), импорт/экспорт данных, поиск разными способами, обработка событий (после/перед изменением/удалением/добавлением данных). Набор похожий на имеющийся у нас к MTStrTbl.
- отображением данных из датасета - подобная верхней таблица, привязываемая к датасету как к менеджеру. Плюс компоненты работы с таблицей: манипуляции с колонками (скрытие, отображение, перестановка, форматирование без затрагивания данных в датасете), условное форматирование ячеек/строк (как реакция на события датасета), редактирование данных в runtime.

Редактировалось 1 раз(а), последний 2021-08-30 11:28:55

Конечно возникло. Нужно сохранять атрибуты ячеек(Цвет, Шрифт, Стили шрифта и цвет, Align - Выравнивание по горизонтали и вертикале) Тут напрашивается либо свой формат сохранение/загрузка данных либо расширенный csv файл (что существенно может повлиять на скорость).
Что касается VirtualTable есть у меня портированный вариант. Присобачить особой сложности не вижу пока.
Пока думал только реализовать все методы от StringTable для начала но как обычно загвоздка от FPC, компилируется но падает в RunTime.
Перенос строк и колонок присутствует, просто в пример эти опции не включены.
Netspirit, если есть желание помочь буду благодарен.

Да у меня что-то все реже появляется вдохновение сесть и углубиться в кодинг. Есть некоторые идеи, вынашиваемые уже годами, но так и не начатые.

По поводу реализации. Нужно разделить хранение данных и отображение. Вот твою VirtualTable можно допилить до требуемого функционала. Она должна быть в виде базового класса, содержащего все методы и события для работы с данными в отдельном *.pas файле. На основе него отдельный компонент "VirtualTable" и компоненты для манипулирования данными в нем.

Затем твоя или любая другая визуальная таблица. В ней отпадает необходимость заниматься хранением данных: она подключается к VirtualTable как менеджеру (или компонентам работы с БД, которые тоже внутри хранят данные так же, как и VirtualTable) и получает от него все что надо. Колонки, строки, значения колонок в каждой строке, события на перед/после загрузки данных/модификации значений/добавления-удаления строк-колонок. При этом сам компонент теряет кучу точек для работы с данными (как случилось при переходе от MTStringTable к MTStrTbl).

Достаточно в классе VirtualTable предусмотреть добавление пользовательских данных к любой строке по ключу - визуальная таблица хранит свои атрибуты, какой-то другой компонент - свои. Интерфейс VirtualTable имеет методы добавления/чтения таких данных. Поскольку он не должен ничего знать о формате этих данных - он предоставляет события на добавление/удаление строк, чтобы визуальная таблица сама могла удалить прицепленные данные.
При этом к каждой строке это необязательно: изначально визуальная таблица имеет форматирование по-умолчанию для каждой колонки. Если разработчик схемы хочет отформатировать какую-то ячейку в строке - добавляется отдельный компонент "Форматирование ячеек" как менеджер к визуальной таблице. На каждое событие отрисовки строки таблица уведомляет все такие компоненты чтобы те дали нужные данные. В этом компоненте сразу можно давать точки со значениями отдельных колонок нужной строки и пользователь на основе их значений задаёт форматирование (или форматирование уже задано в компоненте, пользователь только принимает решение включать его, или оставить стандартное согласно таблице). Опять же - уменьшаем количество точек у визуальной таблицы.
А вот если пользователь программы выбирает ячейку и щелкает на панели инструментов "жирный шрифт"/"выравнивание", то его форматирование цепляется уже к конкретной строке. Почему к строке - если цеплять к каждой ячейке, то у каждой ячейки должен быть список прикрепленных данных, что накладно по памяти; строк меньше, чем ячеек, а к строке прикрепляется структура, содержащая форматирование для каждой ячейки строки.


Уменьшаем дальше количество точек-свойств таблицы: добавляем отдельные компоненты для добавления/удаления/перемещения/скрытия/отображения колонок, связывания их с колонками в VirtualTable (колонки в VirtualTable должны иметь такие свойства как Name, Title), и другие, которые относятся к визуальной таблице, а не к данным в ней (в VirtualTable), например, экспорт в HTML/RTF с форматированием.

Таким образом, например, большая часть существующих компонентов от MTStrTbl (манипулирование строками-колонками-значениями, импорт-экспорт, сортировка-поиск) на самом деле должны перекочевать к VirtualTable. А у MTStrTbl остаться только форматирование и связывание отображаемых колонок с колонками в VirtualTable (по свойству Name), предоставление редактирования значений.

В визуальной таблице задается связь к менеджеру VirtualTable. Перечень колонок задается в виде
"<name1>=<width>=<format>=....."
"<name2>=<width>=<format>=....."

где <name> - из требуемой колонки VirtualTable. Заголовок колонки берется из соответствующего Title.

Фактически функционал визуальной таблицы сводится к чтению данных из подключенной VirtualTable и отрисовке в окне.

Редактировалось 11 раз(а), последний 2021-08-31 14:09:07

Netspirit,
объектная модель для программирования в KOL(delphi)
type
PStGrdData = ^TStGrdData;
TStGrdData = object(TObj)
исключены из конструктора в приват секцию (всё по феньшую THIWin для HiAsm)
Сама сетка самодостаточна для расширений которые ты описываешь. VirtualTable может и не понадобится.
Урожай соберём дальше будем думать над форматом файла.

p.s В любом случае спасибо за поддержку.

С большим трудом удалось таки собрать рабочую версию под FPC
Появился стимул пилить дальше

Дон Педро, ты не сердись, но я тебя уважаю и люблю!
Как ты думаешь?
https://gamedev.ru/art/forum/?id=85236&page=10

Редактировалось 1 раз(а), последний 2021-09-03 22:42:24

А что думать там.
Люди делятся своими достижениями и неудачами.
Искусство писать (рисовать шедевры) всегда дано свыше.
Так что через голову нефиг прыгать.

Сегодня по конференссвязи с нами был психолог, который блеял что сокращение это не конец света.
"Если у Вас отягощения мыслей выгляните в окно, там обязательно будет красивая машина, красивое дерево" и т.п бред полный короче.