Всем привет, может кто подскажет - нужно получать смс через GSM модем
с использованием библиотеки MSCOMMLib.MSComm.1 для работы с СОМ портами (MSCOMM32.OCX)
Не могу понять как заставить срабатывать событие OnComm когда в порт приходят данные.

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

А какие варианты кроме опроса порта фоксом (с разумной частотой, например 1 раз/сек) ?

а как же события? или не работает. нашёл пример: Как передавать и получать двоичные данные с помощью элемента управления VFP MSComm32 support.microsoft.com

а вот что нашел: Для события OnComm, необходимо задать свойство Rthreshold в значение, отличное от нуля (по умолчанию). Обычно значение свойства RThreshold равно 1, что означает, что OnComm событие происходит, если хотя бы один знак находится в состоянии ожидания во входном буфере.

кажись заработало....



Исправлено 2 раз(а). Последнее : 346, 05.12.18 19:53

Конечно ничего опрашивать не надо.
Событие OnComm срабатывает при приходе 1 го символа.
Думайте как дождаться окончания передачи, что бы прочесть все разом.
Либо какой то алгоритм, для получения.

У меня всегда короткая, одинаковая передача. Потому после срабатывания, короткой паузы хватает

не надо ничего ждать - считывать надо сразу, иначе тупо закончится место в буфере (он для MSCOMM весьма невелик). А вот считанные "символы" (в зависимости от скорости порта и собственно программы она может и не успевать "по одному" их получать - может в input уже несколько будет как код дойдёт до чтения свойства) уже вполне можно накапливать в том же свойстве формы, или поле таблицы, и потом уже отдельно обрабатывать - скажем для обычных AT команд-ответов искать символы конца строки, бить по ним принятые данные и разбирать...

Когда-то делали "многотерминалку" под ДОС, у нас был самодельный контроллер (несколько КР580ВВ51), он обеспечивал аппаратные прерывания по событиям (Rdy - прием, окончание передачи, CTS, еще что-то). Теоретически механизма прерываний вполне достаточно, но на практике прерывания иногда, редко, но "терялись". Почему терялись - хз, вот не происходили и всё, точнее ПО компа их не видело. Если ориентироваться только на прерывания, то это смерть многотерминалки, т.к. вовремя не обрабатывается событие. Поэтому параллельно с механизмом прерываний все же пришлось сделать и опрос по таймеру, раньше назывался "поллинг". Например, в ДОСе для этого есть таймер 18.2 раз в сек. срабатывает вроде, которого оказалось достаточно и без аппаратного прерывания...

есть же InBufferSize я конечно пока изучаю мать часть и не совсем разобрался... да и по тестировать надо...во общем пока в поиске вообще общей конструкции. вот выдержки из описания:
Свойство InBufferSize Задает размер буфера приема в байтах.
Задает или возвращает размер буфера приема в байтах.
Синтаксис: [Form.]MSComm.InBufferSize[ = nBytes]
Установки: nBytes
Задает общий размер буфера приема. По умолчанию этот размер составляет 1024 байт. а интересно есть ли ограничения на размер буфера...
а вот если задать определенное число например 5 то событие произойдет если прилетит 5 символов?
Свойство RThreshold
Задает или возвращает число символов, которые следует получить до того, как элемент управления Communications установит для свойства CommEvent значение Receive и сгенерирует событие OnComm.

а если передавать то
Свойство SThreshold
Задает или возвращает минимальное число символов, которые можно держать в буфере передачи до тех пор, пока элемент управления Communications не установит для свойства CommEvent значение Send и не сгенерирует событие OnComm

346
а интересно есть ли ограничения на размер буфера

Кажись 32767 байта

346
а вот если задать определенное число например 5 то событие произойдет если прилетит 5 символов?
Свойство RThreshold

Да, каждый принятый портом 5 символ будет генерировать событие OnComm.

Спасибо всем откликнувшимся!
Во общем потихоньку продвигаюсь, не быстро, занят другими делами.
Вот маленько окунувшись в тему пришел к выводу что отправка СМС хорошо иногда почти нет альтернативы, но если отправлять много СМС то оператор может посчитать это спам рассылкой и заблокировать(причем некоторые операторы считаю 10 смс отправленных за определенное время уже спамом и блокируют несмотря на большой остаток из пакета СМС). Хочется сделать такое более менее универсальное устройство, типа информатора, например для таксистов или других фирм где нужно информировать клиентов о тех или иных событиях. Кроме угрозы блокировки оператором, еще и немаловажная цена СМС а она сегодня не маленькая. Использовать спец фирмы которые предлагают отправлять СМС тож не вариант отзывы показали что не всегда СМС приходит быстро иногда по прошествии нескольких часов. т.е. виденье такое: клиент звонит определяем его номер ищем в таблице зареганых номеров клиентов не находим будим оператора или отсылаем на другой номер для связи с оператором, находим смотрим в каком состоянии заказ или др. и формируем текст и произносим его например "Алёнкой". голосовой звонок авто информатором выглядит менее затратным и более универсальным, есть еще конечно звонки через интернет вообще не смотрел особо в эту сторону...
теперь о железе думаю использовать GSM и GPRS модули на "али" они продавались в районе 1 тысячи например SIM900 GPRS/GSM...
Если есть у кого какие мысли по этому поводу, может опыт создания подобного ПО поделитесь.

Не проще ли использовать другие каналы связи с клиентом? Или специфика такова что клиенты это сплошь олдфаги с нокиа 2110, сидящие в глухой тайге без интернета, и кроме как смс и голосовой вызов у них ничего не проходит
Таксисты нынче, я полагаю, всё больше на мобильных приложениях сидят.

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



Исправлено 1 раз(а). Последнее : 346, 23.12.18 15:44

Э не, пенсионеры это совсем другая ЦА. Там не так уж и важна скорость доставки... Просто изобретать свой велосипед в нише где уже и так есть устоявшиеся игроки... Ну я бы не советовал. Выйдет всяко дороже и не более надёжно - с агрегаторами, полагаю, операторы как-то договариваются, а тебя реально забанят "за спам". А "на провода" у нас, насколько я понимаю, до сих пор СМС не ходят - да и опять же ЦА - где ты найдёшь таких людей, у кого проводной телефон да ещё и "в деревне" позволяет СМС принять

Просто SMS-рассылки это бизнес, аффилированный с сотовыми операторами. Вполне логично, что оператор старается блокировать обычному пользователю массовые рассылки. Тупо что б все заключали договоры с их подконтрольными конторами.

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



Исправлено 1 раз(а). Последнее : 346, 28.12.18 09:32

ну так и создавай табличку, с телефонным номером, с атрибутом "проводной", с диапазоном часов, в которые звонить. Делай аппаратуру, которая умеет звонить, или СМСить. Это не программные и не технические проблемы, это просто реализация хотелок, при помощи фокса и железа...