Перевод проекта с Delphi на Lazarus (под Linux)

[Odyssey]

Есть слои в BGRABitmap?

Судя по wiki - нет, хотя есть методы комбинации изображений - возможно это упростит реализацию слоёв. Я сам не работал с BGRABitmap, просто держу её на примете для возможного будущего использования, поэтому подробнее ответить, увы, не могу.

[Ism]

Я тоже переводил код с Delphi на Lazarus , вывод - надо многое затачивать под Lazarus .

Кроме того никто не мешает использовать код зависящий от платформы

{$IFDEF Win32}
{$ifdef Unix}

[sign]

Насчёт деревьев и таблиц.
Я как-то перешёл на VirtualTreeView и в итоге остался на нём.

[Konung]

2 Odyssey
насколько я понял тоже - слоев там нет. хотя комбинировать может. кстати, если я не ошибся - то это и не визуальный компонент а скорее - набор библиотек.
оно как бы можно и его средствами, но дорабатывать прилично.

2 Ism
возможно придется именно так и делать. что до ifdef - то как я понял с этим у лазаря как раз заморочки бывают.

2 sign
юзал сие под делфей. да. бесспорно мощный и шустрый компонент. и весьма гибкий. но удобства/простоты сращивания с датасетом совсем не то... оно и понятно - VirtualTreeView сначала дерево все ж. а у EhLib - это сначала датасет, а потом уж + функционал дерева. возможно от этого он малость ролигрывает, но все решаемо

[alexs]

Vadim писал(а):Вам предложили RxMemTable. Этот компонент Вас чем-то не утсраивает?
не в курсе потребностей автора темы - но в ном есть работа с деревьями?

Зачем в плоском наборе данных деревья?
Или вы что-то не рассказали?

[Konung]

2 alexs
ммм... да я вроде как и не рассказывал суть цели и задачи проекта .
если в кратце - то используются и "плоские" данные водних случаях, и плоские+древовидные в других (часто - удобно иметь много сразу визуально и дерево и колонки датасета и т.п. моменты)
(что бы не возникао путаницы - то деревья в данном случае я имею ввиду - логически и визуально что то вроде стандартного TTreeView, а не теорию графов, обобщенные деревья структур данных или математические алгоритмы и т.п.)

[alexs]

(часто - удобно иметь много сразу визуально и дерево и колонки датасета и т.п. моменты)

вот честно, ни разу не понадобились такие выкрутасы.
Если есть желание - присоединяйся к доработкам компонентов.
Будет и тебе счастье...

[sign]

(часто - удобно иметь много сразу визуально и дерево и колонки датасета и т.п. моменты)

вот честно, ни разу не понадобились такие выкрутасы.

Ну, это дело по потребностям.
Мне вот, нужно.

1.png

2.png

[alexs]

Ну на самом деле вариант с группировкой решается на базе стандарного грида достаточно просто. Дополнительное поле + Ручная отрисовка колонки + Фильтры данных.

[Konung]

2 alexs

вот честно, ни разу не понадобились такие выкрутасы.

ну согласитесь - если не понадобилось вам - это не значит, что подобное не нужно никому... оно ж ведь людей много - не вы один .

Если есть желание - присоединяйся к доработкам компонентов. Будет и тебе счастье...

с удовольствием бы. если бы не куча всего, что мне приходится делать. грид+дерево - это лишь одна из небольших частей. важных, но не единственных. если не получится иначе (или в принципе не определимся с переходом в иную среду разработки), то можно заюзать и VirtualTree. хотя имхо - это хоть и навороченная вещь, но не столь удобная как то что сделано в EhLib.

Ну на самом деле вариант с группировкой решается на базе стандарного грида достаточно просто. Дополнительное поле + Ручная отрисовка колонки + Фильтры данных.

на самом деле - все это будет не так хорошо работать как вам думается:
- с отрисовкой еще надо солидно повозиться если хочется, что бы было все цивильно. речь ведь не идет о 1-2 уровнях. а о довольно крупных деревьях с вложениями 10-20 и более уровней. проводить предварительный рассчет по всем полям что бы определить отступ - потребует времени.
- одним полем не факт что одойтись. возможно 2 или 3 (возможно больше - не обдумывал еще досконально). потому как будет желательно хранить уровень, флаг открыт/закрыт, и т.п.
- фильтры. ко всему вышше сказанному - для фильтра надо будет построить те самые поля, определиться с фильтрующим полем (полями), и произвести саму процедуру фильтра. что не есть шустро. потому как, опять же, речь не идет о деревьях в 10-20 позиций. а это 50-60 тысяч записей. возможно будет больше (в планах 100-120 т.з.). повесить это все + фильтр на функционал обычного датасета (пусть и в памяти) - нерационально и, возможно, - тормозно. а если поверх этого надо еще и пользовательскую фильтрацию наложить... ?

по сути - надо делать именно структуру дерева в памяти, со всем его типичным функционалом, связывать элементы дерева с записями датасета, дорабатывать отрисовку грида при подобном деле. собственно все это и сделано в EhLib.

2 sign

вот как то так это выглядит в ehlib-е. убраны горизонтальные линии, иконки по OnPaint (хотя можно и иначе. мне так было проще)
в остальном (в простом случае) - указать SQL, связывающие поля дерева и всё... (у мя чуть сложнее - для шустрой загрузки)

[sign]

В принципе, есть такой вот компонент - для работы с датасетом. (жмакать кнопку "Internal Mirror 1")
Потомок VirtualTreeView.
При желании можно завсегда допилить под себя.

[Konung]

2 sign
мерси. качнул. погляжу.
года 2-3 назад юзал VirtualTree с некой надстройкой для упрощения работы с базой. недурно весьма, хотя с ehlib-ом в итоге понравилось больше. возможно что то в том же духе, или то же самое. но погляжу непременно.