Все таки для FPC более интересен проект Lazarus, который может собирать приложения для Linux, FreeBSD, Mac OS X, Microsoft Windows, Android. Именно на него и стоит ориентироваться.

Чтобы сделать такой http://forum.hiasm.com/getfile/37895 компонент, в понятиях KOL, мне потребовалось три дня.
Не сомневаюсь, что кто-то и за день сделает.
А чтобы переделать готовое и просто добавить точки и нарисовать иконку нужно не более пары часов.
Вот и весь сказ.

Редактировалось 2 раз(а), последний 2016-10-28 11:08:33

Netspirit, проверь схему SpeedTest в Elements\delphi\Example\FTCG - почему тут FPC быстрее в 5 раз?

Добрый день.

Что нужно дописывать в Share.pas и что в конкретный элемент? Это стандартная запись? Можно ли самостоятельно внести соответствующие записи в интересующие сторонние компоненты? К примеру в NumberToString.

Можно взять Share.pas из адаптированного пакета из этой темы. Но то, что он будет заменен у каждого индивидуально значит, что компонент не будет работать у остальных.

Уточняю:
1) Для работы с новым FPC x32 практически никаких изменений вносить не нужно, но в случае наличия ошибок компиляции/работы компонента можно внести такие правки в этот компонент, которые будут работать в оригинальном и адаптированном пакетах без дополнительных изменений.
2) Для работы стороннего компонента в адаптированном пакете под 64-битным FPC, кроме первого пункта нужно поправить компонент для поддержки 64 бита.
Для работы такого компонента в оригинальном пакете в файл каждого компонента нужно добавить запись
либо выложить на SVN измененный Share.pas, в котором эта запись присутствует.

--- Добавлено в 2016-10-31 12:51:54

Наверное, такие особенности компиляторов. По кнопке Classic (200 000 циклов) действительно FPC в 5 раз быстрее. А вот по кнопке FTCG (100 000 000 циклов) FPC уже в 8 раз медленнее. То же, но 10 000 000 циклов - на 25% медленнее.

Редактировалось 5 раз(а), последний 2017-12-04 12:10:30

Есть один вопрос. В ListEdit.pas есть кастомный контрол TListEdit, который используется, в частности, в StringTable. Для обработки сообщений в этом классе используется подмена оконной процедуры с помощью MakeObjectInstance(NewWndProc). Больше нигде в других компонентах это не применяется. Почему не используется TControl.OnMessage или TControl.AttachProc?

И ещё. В стандартном примере Example\Forms\MTStrTbl\With_EditCtrl.sha вылетает ошибка при попытке изменить мышью ширину столбца таблицы (на всех компиляторах).

Чсзать, я так и не понял, почему. Может попробуешь найти откуда ноги растут у этого бага?

А вот ListEdit.pas не моя разработка, потому ничего не могу сказать про то, что там накручено.

Не хочет компилировать когда в схем есть strMask

Редактировалось 2 раз(а), последний 2016-10-31 21:10:18

Уже нашел и исправил.

Редактировалось 1 раз(а), последний 2016-11-01 00:58:57

У меня компилирует и работает. Может, что-то другое мешает? Что пишет в "Отладке"?

Спасибо.

Редактировалось 1 раз(а), последний 2016-11-01 11:46:08

В большой схеме в отладке пишет:
"hiMultiElement_1B8AC00.pas(1102,36) Error: Identifier not found "Create_hi"
hiMultiElement_1B8AC00.pas(1103,36) Error: Identifier not found "Create_hi"
hiMultiElement_1B8AC00.pas(1245) Fatal: There were 2 errors compiling module, stopping
"
После удаления из схемы strMask, находящегося в MultiElement, схема компилируется и работает.
Схема из формы и самого strMask:
Сразу по завершению компиляции выскакивает окно с ошибкой:

В других версиях компилятора такой ошибки нет, в делфи тоже.
Если задать данные для сравнения и саму маску то программа из формы и strMask компилируется и работает.
Выйти из ситуации можно если исключить поступление в потоке, или на верхнюю точку данных типа NULL:
Могу только предположить, что для этого компилятора в компонент нужно внести какие-то изменения (типы данных изменить или еще что, не профессионал - не знаю)

Редактировалось 7 раз(а), последний 2016-11-01 21:56:21

nesco, не работает текущая реализация этого компонента.
1) Поле CustomData автоматически освобождается по FreeMem(fCustomData) в деструкторе TControl.Destroy, а мы в него заносим THIMST_UseEditCtrl, который должен освобождаться по TObject(fCustomData).Free. Это приводит к падению при закрытии программы (на компиляторе Delphi не всегда заметно, поскольку, видимо, не успевает выдать сообщение об ошибке, на FPC - стабильно падает).

2) Компонент THIMST_UseEditCtrl создается и уничтожается автоматически. Поэтому такая цепочка могла бы приводить к падению при закрытии программы (но по причине первого пункта не выполняется):
- уничтожается ThiMTStrTbl
- в ThiWin.Destroy уничтожается контрол в поле Control
- TControl.Destroy уничтожает прописанное в CustomData, то-есть, наш THIMST_UseEditCtrl
- следующее автоматическое уничтожение THIMST_UseEditCtrl пытается уничтожить уже уничтоженный объект

Исправить можно, если в CustomData прописывать не Self, а созданную по GetMem переменную типа PPointer, в которую занести Self. Тогда FreeMem(fCustomData) освободит эту переменную, а THIMST_UseEditCtrl останется нетронутым.

3) Но это - тупиковый путь. ThiMTStrTbl тоже назначает свою оконную процедуру. Для доступа к самому себе из этой процедуры, он прописывает себя в Control.Tag. Как мы уже убедились, THIMST_UseEditCtrl тоже хочет добавить свою процедуру, а поскольку поле Control.Tag уже используется, то пришлось себя прописывать в CustomData. А если будет третий компонент, которому тоже нужно будет обрабатывать сообщения от этого Control? Куда он себя пропишет?
Это, видимо, является причиной вопроса и к ListEdit.pas.

НУЖНО:
- ловить сообщения от Control только в ThiMTStrTbl либо через AttachProc, либо по перекрытию ThiWin._onMessage.
- добавить в ThiMTStrTbl поле PList и пару методов SubscribeToMsg(MsgMethod: TOnMessage)/UnsubscribeFromMsg(MsgMethod: TOnMessage).
- каждый клиент к менеджеру ThiMTStrTbl, который хочет получать сообщения (например, наш THIMST_UseEditCtrl), вызывает SubscribeToMsg и указывает метод, который нужно вызывать при поступлении сообщения
- метод ThiMTStrTbl.SubscribeToMsg создает список подписчиков PList (если ещё не создан), и добавляет туда этот метод
- в процедуре обработки сообщений ThiMTStrTbl обрабатывает интересующие его сообщения, а потом пробегается по PList и передает сообщение всем подписавшимся обработчикам.

Поскольку такой подход может требоваться и в других компонентах, то, чтобы не повторять эти методы в каждом таком компоненте, это можно интегрировать прямо в ThiWin. Получается, если визуальный компонент наследует ThiWin, то к такому компоненту можно будет подписываться на сообщения без плясок с Control.Tag, Control.CustomData (потому, что они позволяют подписать только 2 компонента, ну и ещё наследник может перекрыть ThiWin._onMessage).

Дополнительный вопрос. Я не в курсе, как происходит процес уничтожения связки менеджер-клиент. То-есть, когда мы в клиенте указываем менеджера в свойстве _prop_MSTControl, клиент сохраняет ссылку на него у себя. Что будет (если такое возможно), если менеджер будет уничтожен раньше, чем клиент? Клиент ведь будет и дальше обращаться к несуществующему менеджеру.

Редактировалось 2 раз(а), последний 2016-11-02 12:43:41

А что делать, если надо перекрыть аналогичный обработчик в ThiMTStrTbl, что, кстати, и делает THIMST_UseEditCtrl, он дает команду на удаление обработчика ThiMTStrTbl и переназначает свой?. Тут я не очень понял.
Кстати, а у тебя есть готовый пример такой реализации подписки на обработку сообщений?

--- Добавлено в 2016-11-02 14:13:23


Чсзать, я не рыл этот вопрос, тут автора технологии менеджеров (Dilma) спрашивать надо.

Редактировалось 1 раз(а), последний 2016-11-02 14:13:23

Где? Не вижу. Он просто добавляет ещё один обработчик через AttachProc(). KOL это предусматривает - AttachProc/DetachProc реализованы через список, и мы могли бы этим воспользоваться, если туда можно было бы передать метод объекта, а не простую процедуру - в простой процедуре мы вынуждены плясать с CustomData, так как не имеем другого доступа к нужному экземпляру THIMST_UseEditCtrl (в таких случаях должна быть предусмотрена передача пользовательского параметра в AttachProc, что решается, если мы сделаем свой вариант, принимающий метод объекта).

Сейчас работаю над этим.

Обработчик WndProcTabGrid есть и в ThiMTStrTbl, и в THIMST_UseEditCtrl, поэтому первый надо заменить

Редактировалось 1 раз(а), последний 2016-11-02 14:41:26