Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2005.12.11;
Скачать: CL | DM;

Вниз

Проблема с Socket.ReceiveBuf   Найти похожие ветки 

 
Gektor   (2005-09-01 11:31) [0]

В событии OnRead пишу:

var i : Integer;
   Len : Integer;
   pbuf : PMyArray;

begin
{Принимаем данные и ложим сразу в конец IncomingBuff}
while (Socket.ReceiveLength > 0) do
begin
Len := Socket.ReceiveLength;
i := 0;
try
pbuf := Pointer(fIncomingBuf^[fIncomingBufLen]);
i := Socket.ReceiveBuf(pbuf,Len);
except
AddToDebugLog("Error with receiving Some Data");
end;

и тд...

в Отладчике в первый же раз, при выполнении строки i := Socket.ReceiveBuf(pbuf,Len); выдает окошко CPU и вылетает с ошибками.

Буферы точно созданны.
fIncomingBufLen = 0.
В Len не нулевое значение.
PMyArray Указатель на array[0 .. 7999]

В чем можеть быть проблема?


 
Digitman ©   (2005-09-01 11:53) [1]

Паскаль нужно знать как "Отче наш" !

i := Socket.ReceiveBuf(pbuf^,Len);

к тому же еще и логика неверна ..
зачем тут цикл понадобился, спрашивается ?


 
Gektor   (2005-09-01 12:13) [2]


> Digitman ©

i := Socket.ReceiveBuf(pbuf^,Len); и сразу отрабатывает OnError


 
ALI_YES   (2005-09-01 12:23) [3]

Действительно Паскаль надо знать.
Но если тебе надо передавать большие объемы данных, то тебе лучше испльзовать класс TWinSocketStream.


 
Digitman ©   (2005-09-01 12:44) [4]


> сразу отрабатывает OnError


это уже из другой оперы.

к тому же никаких "сразу" быть не может.

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

Учимся пользоваться встроенным в Делфи-среду отладчиком !


 
Digitman ©   (2005-09-01 12:47) [5]


> ALI_YES   (01.09.05 12:23) [3]
> если .. надо передавать большие объемы данных, то ..
> лучше испльзовать класс TWinSocketStream.


глупости.

возможность и/или необходимость использования класса TWinSocketStream никак не зависит от объемов транспортируемых данных

возможность зависит от Client/ServerType

необходимость зависит от реально имеющейся возможности + фантазии


 
ALI_YES   (2005-09-01 12:52) [6]


> Digitman ©   (01.09.05 12:47) [5]

Я знаю, просто кому-нибудь это показалось бы удобней


 
Digitman ©   (2005-09-01 13:25) [7]


> ALI_YES   (01.09.05 12:52) [6]


судя по OnRead ни о каких TWinSocketStream не может идти и речи.
автор выбрал асинхронный неблокирующий режим.


 
ALI_YES   (2005-09-01 14:30) [8]


> Digitman ©   (01.09.05 13:25) [7]

Хорошо, пусть он выбрал.
Но, ты считаешь, что

> асинхронный неблокирующий режим.
более удобен?


 
Digitman ©   (2005-09-01 14:37) [9]


> ALI_YES   (01.09.05 14:30) [8]


я считаю, что прежде чем давать советы в [3] нужно внимательно изучить сабж.

сабж же говорит об выборе (осознанном или неосознанном - неважно) автором режима ctNonBlocking, для которого TWinSocketStream неприменим в принципе.


> более удобен?


причем здесь "удобство" ?



Страницы: 1 вся ветка

Текущий архив: 2005.12.11;
Скачать: CL | DM;

Наверх




Память: 0.49 MB
Время: 0.039 c
2-1132947934
Kot
2005-11-25 22:45
2005.12.11
Нажтая клавиша в кодировке ANSI


1-1132124995
DEMs
2005-11-16 10:09
2005.12.11
Компонент TVirtualStringTree


3-1130138638
syte_ser78
2005-10-24 11:23
2005.12.11
украинская локализация


11-1113674934
Dot
2005-04-16 22:08
2005.12.11
VCL, KOLForm & uses mirror


2-1132926394
Graf
2005-11-25 16:46
2005.12.11
Перехват разрешения экрана