Запутался и немогу понять, как можно реализовать добавление нового Event в компоненты TClientServer, TServerClient

Есть стандартные seRead,seconnect и т.п. Где и как можно реализовать добавление новой команды.

Поконкретнее - какой команды?
В общем случае - только править исходники ScktComp.pas, что без должного знания дела настоятельно не рекомендую.

Я вообще то и говорю про ScktComp.pas

как можно реализовать добавление команды в TSocketEvent 

Мне казалось, что все необходимое уже добавлено. Правьте тип TSocketEvent, сохраняйте ScktComp.pas в папку с проектом и в путь.
Вот только, может быть, Вам не нужен Х ?
Что конкретно Вы хотите туда добавить?

Допустим мне нужна новая команда.

client отправляет эту комнду сервер должен принять и установить чтение команды.

event(self,seCommand);


Хорошо, как работает система отправки TSocketNotifyEvent.

Client отправил сообщение, а на server приходит сообщение через чтение TSocketNotifyEvent.

Так вот вопрос, как мне сделать тоже самое? С другой командой.

Стоп.
Не нужно путать возникновение событий в результате соединения/приема/передачи трафика и сам трафик.
Передача чего-либо клиентом на сервер и наоборот - это трафик, никоим образом не относящийся к событиям TCustomWinSocket.

Если клиент что-то отправил, то на сервер в любом случае что-то придет (всякие разрывы соединения в расчет не берем). Что конкретно пришло на сервер можно выяснить при обработке seRead.

Добавлено @ 21:50

Чуть оффтопика:
Это утверждение или вопрос? Если утверждение, то соглашусь - действительно, хорошо-то как работает 

Это сообщение отредактировал(а) kami - 5.2.2010, 21:51

То есть добавить событие я не смогу?

Вообще вопрос, в том что мне нужно принимать и сообщения, и буфер одновременно.
По-этому я хотел добавить чтение нового события seReadText.

Для сетевых компонентов глубоко симметрично, что через них передается - строки, буферы памяти, различные потоки - всё воспринимается как чистые данные. Сетевые компоненты не знают (и не должны), какими были исходные данные. Более того, они даже не знают при приеме их размер (попробуйте отправить в соединение '123' и следующим оператором '456'. На приеме Вы получите (скорее всего) '123456' - за ОДНО событие OnRead). Как интерпретировать входящий трафик(т.е. какой взять приемный буфер) - это Ваша проблема, и задаваться она должна определением Вашего (пользовательского) протокола обмена. И никакие добавления seReadText, seReadFile здесь не помогут, т.к. (повторюсь еще раз) - для сокетов все, что пришло это чистый поток данных. Определяйтесь с тем, что пришло из соединения в предназначенных для этого событиях.

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

Добавить - сможете. Но кто будет его вызывать? Кто и Как определит, что нужно seReadText, а не seRead?
Ну и - 

Вопрос изначально, что означает вот эта установка:  

    property OnClientConnect: TSocketNotifyEvent read FOnClientConnect write FOnClientConnect;

    property OnClientConnect: TSocketNotifyEvent index 2 read GetOnClientEvent write SetOnClientEvent;

Откуда мы получаем событие?

И что значит этот код:
    OnClientConnect: TSocketNotifyEvent


Это сообщение отредактировал(а) 2134 - 14.2.2010, 12:55

см. TCustomWinSocket.CMSocketMessage

Не понял вопроса.

Если вопрос про то, как назначаются события, то увы - не ко мне. Не смогу прочитать курс лекций по объявлению, назначению и использованию методов, про различные уровни видимости, абстрактные, виртуальные и динамические методы.

Не могу понять, в ваших словах нет помощи, к чему они вообще?

Как например: "У вас знаний не хватает" - Я и сам прекрасно понимаю, что у меня их не хватает, вот я и пытаюсь найти ответ в поставленной для меня задаче.

А так, как было выше написано, спасибо за внимание.


TCustomWinSocket.CMSocketMessage - как я заметил уже два дня назад, это работа с клиентом, а мне нужна работат с сервером.

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

Вы хотите влезть в исходники VCL. Это хорошо, но чревато, о чем я уже писал.

На один из вопросов, а именно - 

я ответ дал.
Остальные не понял, о чем честно и написал. 
Что означают события - имхо, ясно из их названия.
Как они назначаются - всё начинает "плясать" от процедуры InitSocket.
Если смущают индексы - то это к справке, ибо относится к синтаксису Delphi, а никак не к конкретным компонентам.

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

TCustomWinSocket используется и в клиенте, и в сервере. Ибо является предком TClientWinSocket и TServerWinSocket. Более того, в каждом событии TServerSocket одним параметром идет TCustomWinSocket, который является хозяином соединения, вызвавшего событие.

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

Как они назначаются - всё начинает "плясать" от процедуры InitSocket.

Тут и так понятно, что назначается асинхронное соединение с клиентом.

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

В пределах:
property OnClientRead: TSocketNotifyEvent index 0 read GetOnClientEvent write SetOnClientEvent;

Все и обрывается, а дальше не могу понять, как мы узнали, что потребовали запрос на это событие: 
1) Кто потребовал запрос.
2) Что за событие.

Вот все, что я и хочу узнать, а остальное, обработать это событие назначить ему применение, доделаем.

У меня почти вся программа написана, а из-за этой проблемы ломаю голову 3 день

Добавлено @ 02:46
Извиняюсь, но теперь я начал понимать, спасибо.

Я изначально не дал большего значения вот этому.


Это сообщение отредактировал(а) 2134 - 14.2.2010, 12:55

Пойдем сначала:
когда в открытое в нашем серверном сокете соединение пришли данные, система (Windows) отправила CustomWinSocket-у, ответственному за это соединение (точнее, его окну) сообщение.
CustomWinSocket поймал его в процедуре  CMSocketMessage.
Дальше пошла его обработка (берем сообщение о том, что что-то пришло из сети):
1. Вызывается процедура Read
2. В ней Event(Self, seRead);
3. Оттуда оно "перенаправляется" в TServerWinSocket.ClientEvent
4. В TServerWinSocket.ClientEvent вызывается ClientRead
5. Из ClientRead попадаем в TServerSocket.OnClientRead, а оттуда - в Ваш код.

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

Добавлено @ 02:57

Да это я уже понял, спасибо. Вы решили все эти проблемы с сервером.
А то меня это уже начало пугать, как мы можем получать событие из пустоты, прям камень с груди.

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

Не клиент делает событие, а 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

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