Совет нужен. Кто имел опыт создания своих компонентов DesignTime в

Lazarus. Есть невизуальный класс, для которого хочу попробовать сделать невизуальный DesignTime компонент на палитру. Сейчас в раздумье. Чтобы создать свой DT невизуальный компонент нужно будет его сделать наследником TComponent.
Изначальный RunTime класс сделан на основе TObject (ну не нужны мне были фишки TComponent). Вопрос: что делать?
1) Изменить изначальный RT класс?
2) В конструкторе нового DT компонента создавать объект RT компонента. НО не красиво: придётся дублировать все процедуры или при использовании придется постоянно обращаться через дочерний RT класс.

Итак, я реализовал первый способ: fptelegram_dt.lpk Первая версия компонента: Это готовый longpolling телеграм бот, который вы можете использовать для быстрой разработки ботов для телеграм. здесь о longpolling телеграм ботах. Этот компонент можно использовать в приложениях с графическим и не графическим интерфейсом, демонах и службах и даже на веб-сервере (хотя на веб-сервере я предпочитаю web-хуки). Реализовал создание клавиатуры для телеграм ботов в дизайн-тайм. Простой пример использования: https://github.com/Al-Muhandis/fp-telegram/tree/master/examples/DesignTime и почти никакого кодинга.

Я его использую уже год. Спасибо Вам. С моими навыками "закинуть на форму и написать обработчик" визуальный компонент это ещё лучше :)

Он пока сырой (в смысле функционала, нужно будет докинуть множество методом и событий из основного raw класса TTelegramSender), так что если какой функционал нужно могу сделать акцент на этом. А если будут пуллреквесты - еще лучше )

Через события работает?

Renat Suleymanov
Да, пока правда только три события из TTelegramSen...

А многопоточность?

а зачем, сетевое соединение же все равно одно

Если рантайм компонент реализуешь самостоятельно. В дизайнтайме: все в коробке. Он именно рассчитан для быстрой и несложной разработке. Все внутри создается

Да как бы соединение одно, а запросов как бы много

Не-не. ТАм действительно без многопоточности не обойтись. Как минимум для приема обновлений

создавать поток на запрос - это плохая идея, вредная даже

Создавать Таск - не вредная

но не на уровне же диспетчера

TThreadList.Add про Omni не говорю, но его на лазаря никто видимо не станет портировать

TTask TThreadPool Для Делфи

Вообщем там так: если райнтайм классы, то многопоточностью управляешь самостоятельно. ХОть пуллы задач, хоть много потоков, хоть один

для дельфы я просто сделаю InputCollection.Put( <record с данными запроса> )

Этот компонент без тредов?

Без. В режиме лонгполлинга идет опрос обновления на телеграм сервер. В случае получения апдейта, обработка его осуществляется в основном потоке. Пока так: для большинства задач норм.

А, ок

В смысле поток есть. Но обработка апдейта, которые делает пользователь на событии делается в основном потоке

а что такое "в случае получения" ? я тебя там блокирующий запрос в отдельном потоке, или асинхронные I/O Completion ?

Нет там запросов

что такоеvcomet / long polling ?

Там цикл на опрос сервера, где ответ может лететь до минуты

опрос делается запросами 😊

Одним

Renat Suleymanov
Да, пока правда только три события из TTelegramSen...

Опечаток конечно кучу наделал. А не исправлять. Сейчас увидел: callack вместо callback