Шлю AT модему...

Код

function ComFound:shortstring; vaR   HKey: TRegistry;   ValList: TStringList;   i: byte; begin   HKey:= TRegistry.Create(KEY_READ);   try     ValList:= TStringList.Create;     HKey.RootKey:= HKEY_LOCAL_MACHINE;     HKey.OpenKey('HARDWARE\DEVICEMAP\SERIALCOMM',false);     HKey.GetValueNames(ValList);     for i:=0 to ValList.Count-1 do       begin           if Pos('\Device\USBSER',ValList[i])<> 0 then           begin             result:= HKey.ReadString(ValList[i]);             break;           end;       end;     HKey.CloseKey;     ValList.Free;   finally     HKey.Free;   end; end; function WritePort(Command: string):string; var CommPort:string; Written: dWord; answer:array[0..64] of char; hCommFile:THAndle; begin CommPort:= ComFound; hCommFile:=CreateFile(PChar(CommPort), GENERIC_ALL, 0, nil, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0); WRitten:=0; WRiteFile(hCommFile, PChar(Command)^, Length(Command), Written, nil ) ; readfile(hcommfile,answer,64,written,nil); result:=answer; end;

Посылаю любую команду- приложение висит ...

Если ответ меньше 64 байт, то прога будет ждать, пока они не появятся...

p0s0l и как узнать размер ответа если он ещё не получен?
Как тогда правильно ловить ответ модема?

По одному символу. А потом склеивать их в строку.

В вашем случае нужно настроить таймауты порта (структура TCOMMTIMEOUTS). также не забудте про TDCB, потому что устройство не ответит (или ответит не правильно) если настройки порта устройства и порта компьютера будут различны. Тогда можно проверять следующим образом:

Код

if not ReadFile(hComm,a,64,BytesReading,nil) then     Result:=-1; ................  if BytesReading<64 then     Result:=-2; ................  if ControlSum(a) then ................

Вызов функций - синхронный, а это значит, что функция вернет значение только если что-то будет во входящем буфере или если закончится таймаут отведенный на чтение. Есть еще один способ вернуть значение функции немедленно: поставить CommTimeouts.ReadIntervalTimeout:=MAXDWORD;
но тут самому надо устанавливать задержки перед чтением (типа sleep(100)). Если у вас есть нормальная документация по модему - то этот вариант вам скорее всего не понадобиться.

рекомендую: статья Олега Титова http://www.rs232.ru/doc002.html

Цитата

рекомендую: статья Олега Титова http://www.rs232.ru/doc002.html

Для начала сойдет. Однако, не стоит заморачиваться с описанным там асинхронным вводом/выводом. Лучше использовать потоки. Тем более, что некоторая информация об асинхронном в/в приведенная в указанной статье, вызывает серьезные сомнения.

Петрович, согласен что описание асинхронного в/в оставляет желать лучшего, но в остальном тема раскрыта неплохо. Использование асинхронного вызова целесообразно в случае асинхронного обмена с самим внешним устройством. Потоки в этом случае только усложнят дело.

Цитата(Unregistred @ 9.11.2005, 10:18)

Использование асинхронного вызова целесообразно в случае асинхронного обмена с самим внешним устройством. Потоки в этом случае только усложнят дело.

По моему мнению так:
Если инициатором обмена является перефирийное устройство, тогда возможно асинхронный в/в будет удобнее. А если речь идет о модеме, то тут обычно реализуется диалог - команда-ответ, команда-ответ. Такое гораздо проще строить в потоке.
Но, это дело вкуса.

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

Цитата(AKN @ 12.11.2005, 19:30)

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

Правильно. Главное только не ошибиться с выбором компонента. Некоторые бывают с ошибками написаны .

Цитата

Некоторые бывают с ошибками написаны .

Так по советуйте, в котором нет ошибок