nesco добрый день!

Не могли бы вы объяснить чем отличаются данные компоненты в плане работы? (с потоками в том числе)

У меня есть небольшая схема code_36436.txt, если использую стандартный COM - при закрытии invalid point operation, если использую ваш COMEX - закрывается приложение без ошибок.

Хотел бы узнать причину столь странного поведения...

COMEX не нужно управление чтением, он будет читать данные по приходу автоматически. Для этого у него есть две точки событий: onRead -- асинхронное чтение в отдельном потоке, нельзя применять с интерфейсными элементами; onSyncRead -- синхронное чтение с основным потоком, как раз для случая работы с интерфейсными элементами. Запись так же происходит не в основном потоке, а в отдельном.


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

nesco,спасибо,но не совсем понял про

Если мне требуется выводить данные из COM порта в Memo как быть в этом случае? данные onRead накапливать в StrList например, а потом другим потоком их выводить в Мемо..ну так это вроде тоже самое получается..
Можно небольшой пример?

Ты как читаешь

onSyncRead выдает те же данные, что и onRead, но только в основном потоке, те в потоке твоего приложения. Если хочешь выдавать в Memo, то используй именно выход onSyncRead

То, что понятно автору, совсем не понятно читателю.
И где тут про основной поток ?
Про основной поток стало известно только после допроса автора.
О ComEX, кроме описания точек, нет ничего нигде - ни в Wiki ни в примерах.

Здесь нет, в ответе есть. Я дал довольно конкретный и развернутый ответ, предвидя именно вопрос про вывод в интерфейсные элементы. И после этого ответа меня снова спросили про то, на что я уже ответил, какова должна быть моя реакция?

Это, в принципе, экспериментальный компонент. Я ждал, что его кто-то развернуто протестирует, но так и не дождался.

Удивил...
На SVN "в принципе, экспериментальный компонент" И как можно "развернуто протестировать" при полном отсутствии описания?
Кстати, даже в старой буке 2006 года выпуска COM-портов уже нет (про новое оборудование даже не говорю.)

Я данный компонент часто использую, стабильный, проблем не возникало (несмотря на то что допускаю ошибки).
На базе данного компонента делал небольшие программы для отправки и получения СМС через 3G модемы, работал с UART, делал тестовые утилиты для купюроприемников.
Что требуется для развернутого тестирования?

Гы. Я не первый -- посмотри последнюю группу вкладки интерфейсы.

Ну и что там описывать? Вот описал, сильно помогло?

На материнке может быть хитрый разъем, который никуда не подключен. И тем не менее это не мешает их применять кому не лень. Да и преобразователи СОМ-USB еще никто не отменял.

Очень много оборудования еще использует COM порты или эмуляцию COM>USB,USB>COM...
Универсальный компонент для работы с устройствами USB я так понимаю в принципе тяжело реализовать, для каждого конкретного случая будет свой IC? Или же в Hiasm работа с USB практически не реализуема?

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

Универсального компонента не сделать, тк как у разных драйверов разный API и

Предполагаю, корректно делать так: Synchronize v1.0.7z

Зачем в компоненте COMEX это делать, когда там предусмотрен метод onSyncRead, работающий по тому же принципу

Возможно в COMEX это и не так необходимо, а вообще, такое нужно, когда основная обработка выполняется в параллельном потоке, а в основном потоке нужны только небольшие действия. Нормально такое сделать, например, в компоненте Thread (с аналогичным событием) - сложно.

Если выдавать не по окончанию работы, а из любого места параллельного потока, то да, такое решение может пригодиться.
------------ Дoбавленo в 13.55:
Добавил компонент Synchronize на SVN. Netspirit, сделай в справке для него описание с примером