Не клиент делает событие, а Windows.
Наглядный пример - передаем с клиента большой файл с помощью SendStream. На клиенте мы вызывали одну процедуру (сколько будет seWrite в этом случае нас не интересует - вызвав SendStream мы отдали все сложности передачи на откуп коду Delphi). А вот сколько событий OnClientRead будет на серверной стороне заранее никто не скажет.

Я опять не в те дебри полез?

Добавлено через 1 минуту и 57 секунд

Чем не устраивает назначение события через инспектор объектов - ServerSocket.OnClientRead?

Это можно не объяснять, а то уже голова от этого кипит.
За 3 дня все изучил и не мог понять откуда мы получаем событие, ошибку допустил.

Допустим клиент отправил событие, на сервере мы полчумаем сообщение сокета.

Вопрос: Как я могу добавить новое сообщение, чтоб сервер получив это сообщение обработал запрос.



Это сообщение отредактировал(а) 2134 - 6.2.2010, 03:07

Мы опять вернулись к началу.
Давайте разберемся с терминологией.
События не отправляются, они возникают в результате чего-либо. Это что-либо в случае наших компонентов будет: готовность к подключениям (Listening)/В ходе подключения (OnConnecting)/ Подключено (OnConnect)/ ГОТОВНОСТЬ к записи (а не запись, как некоторые ошибочно думают) (OnWrite)/Что-то пришло от корреспондента, нужно прочитать (OnRead) и т.п.
И клиент и сервер могут отправлять сообщения. В результате отправки и приема сообщений (которые могут быть различных типов данных, я уже говорил, что сокетам это глубоко симметрично) и возникают события.

Еще раз, тот же вопрос, но с учетом терминологии, пожалуйста.
Только лучше - завтра (вернее, уже сегодня).

Я говорил про эти сообщения:



Могу ли я как-то добавить своё событие и внедриеть его в систему.



Добавлено через 49 секунд
Жду с нетерпением, до завтра.

Нет. Это не сообщения, а параметр сообщения CMSocketMessage.
И если значение CMSocketMessage выбирать можно самому при вызове WSAAsyncSelect, то параметры определены Windows-ом, и именно она определяет, что отправить в оконную функцию TCustomWinSocket. Набора этих параметров, определенных в MSDN, более чем достаточно для полного контроля за сетевым обменом.

Можно, конечно, извратиться и отправить
PostMessage(Socket.Handle, CM_SOCKETMESSAGE, Socket.SocketHandle, MakeLParam(FD_COMM, 0));
но это НИЧЕГО не даст, ибо будет отправлено сокету на СВОЕМ конце сетевого соединения. Корреспондент же об этом не узнает, и в логике работы обмена по TCP - и не должен знать.

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

Эм... может есть решение проблемы, получения "ReceiveBuf и ReceiveText" на один сокет.

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

Думаю, это намного практичнее, чем создавать два сокета и работать с ними двумя.

Это сообщение отредактировал(а) 2134 - 6.2.2010, 04:11

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

И ничто не мешает делать конвертацию буфер <=> строка <=> поток (Stream) в ЛЮБОМ удобном для Вас месте.
Это я про то, что принимать можно как угодно - строками, в буфер. И потом переконвертировать в то, что нужно.


Это сообщение отредактировал(а) kami - 6.2.2010, 12:10

В общем вернулись к тому с чего я начинал.