nesco, именно так. Но curlobj использует curl_h.

Привет! В curl_h же, API-функции описаны. Простое разделение интерфейсов, хочешь -- используй API, а хочешь -- используй предоставленный класс оболочки, кому как удобно

nesco, дык я что - спорю что-ли? И не хуже тебя понимаю общие вещи типа разделения API и ОО-оболочки над этим API.

А я про тебя ничего и не говорил, просто уточнил, не мы же одни читаем форум
------------ Дoбавленo в 12.07:
Я с этой байдой не могу только понять одного, какие параметры и как надо передавать, что бы это все заработало. Я же тебе писал, что в запросах я не силен. К какому серверу, как обращаться и где брать все эти параметры

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

nesco, а что же меня цитировал? А вообще, 99% читающих этот форум разница между путями
и
по барабану - как появятся компоненты, так и будут их использовать, не задумываясь о "начинке" (к чему, собственно, и приучает HiAsm - есть Black box, которая что-то делает, а как он внутри устроен - пофиг).

iarspider, ну ты же не будешь отрицать, что использование API напрямую, намного лучше, чем использование надстроечного класса, и в плане быстродействия, и в плане отведенной памяти. У нас в этом плане компоненты есть похожие по структуре применения API -- SQLite. Ну если хочешь использовать надстроечный класс, то возражать, особо, никто не будет.

А над примером подумай, все равно потом делать надо будет

nesco, автор обёртки очень любит упоминать слово lightweight ("легкая"), и я ему склонен верить. Так что есть основания полагать, что проигрыш от использования tCurl будет не таким уж и большим.

Если использовать только API, то придётся самим писать callback-и (ибо и для сохранения принимаемых данных, и для выдачи отдаваемых, придётся самим писать callback-и). А в tCurl всё это уже сделано.

Сейчас я над документацией к tCurl работаю.

Вопрос: технология "менеджеров" предполагает работу с объектом, которым управляет менеджер, исключительно из класса менеджера, или можно использовать механизм интерфейса только как "виртуальную" связь var-точки SomeHandle_out и data-точки SomeHandle_in?

Не обязательно, если менеджер предоставит указатель на класс, то можно перехватить в клиенте управление классом, сложнее управлять методами и переменными самого менеджера, там интерфейс в менеджере описывать надо

nesco, именно указатель и хочу поиметь. Не мог бы ты быть так любезен и подкинуть код (хотя бы примерный) как это правильно сделать.

Самый лучший пример -- ctrlpoint (получение указателя на контрол) в Win.pas. Само получение указателя описано в FontManger-e, UseExtCursor (те, там, где есть свойство ControlManager)

nesco, понял. Спасибо!
------------ Дoбавленo в 13.07:
Перевёл большую часть документации по tCurl. Осталось перевести описание многочисленных свойств.

Редактировалось 8 раз(а), последний 2021-06-21 04:18:53

nesco, в прищепке - перевод документации класса tCurl. Если что надо из документации по библиотеке - говори, попробую осилить (ибо и это-то замучался переводить).

iarspider, отлично, теперь осталось выяснить какие свойства и методы нужны. И про действующий пример не забудь, где будут применяться дискретно все нужные параметры

nesco, как я уже говорил - все. Небольшое уточнение: колбеки (callbacks, функции обратного вызова) не нужны (куда приятнее событиями пользоваться). Всё остальное - надо.
Как только будет класс tCurl, использующий KOL, можно будет и примеры и компоненты клепать.

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