Использование сокета(клиента) в консольном приложении

← →
Vint45 (2003-09-24 11:13) [0]

Здраствуйте! У меня есть консольный CGI-модуль. После того как он принимает данные от веб-сервера, их необходимо передать дальше на другой сервер по сокетному соединению.
Подскажите можно ли в этом консольном приложении использовать TClientSocket? Если да, то как назначить обработку событий?

← →
Verg © (2003-09-24 11:17) [1]

← →
Alex Konshin © (2003-09-24 11:20) [2]

А зачем тебе тогда нужен этот TClientSocket?
Работай прямо на Winsock2 API.

← →
Vint45 (2003-09-24 11:46) [3]

Конечно я не танке, но мне бы хотелось бы узнать, можно или нельзя работать с TClientSocket в консольном приложении. Ведь работа этого приложения основана на событиях, а в консольном приложении имхо события не поддерживаеются. Если так, то вопрос снят.

> Alex Konshin © (24.09.03 11:20) [2]
> А зачем тебе тогда нужен этот TClientSocket?
> Работай прямо на Winsock2 API.

Спасибо, буду смотреть.

← →
Verg © (2003-09-24 12:02) [4]

Не, ну
Cs:=TClientSocket.Create(nil);
cs.onRead := <Метод класса>

Это что, не канает......?

Как сказал HolACost!, ежу понятно, что ClientSocket создаст окно для своих личных меркантильных целей. ну да и хрен с ним - пусть создает, видно его все равно не будет.

← →
Alex Konshin © (2003-09-24 12:33) [5]

Я просто не понимаю, почему вы за него цепляетесь?
Экономии никакой, а вопросы возникают. Если же писать прямо на Winsock2 API, то и вопроса бы не возникло, а по коду практически тоже самое и выйдет. В Winsock2 нет небходимости в очереди сообщений, как в Winsock (и в TClientSocket соответственно).
Но если по вопросу, то да, в консольном приложении можно работать и с TClientSocket.

← →
Verg © (2003-09-24 12:41) [6]

> Я просто не понимаю, почему вы за него цепляетесь?

Наверно привычка.

Человек, который всегда переплывал реку на лодке, будет еще долго спрашивать при переплывании вплавь: В какой руке держать весла?

← →
Vint45 (2003-09-24 12:45) [7]

> Не, ну
> Cs:=TClientSocket.Create(nil);
> cs.onRead:= <Метод класса>

:) именно так я и делал, но на <Метод класса> меня не хватило. Т.е. подставляю имя процедуры, а компилятор выдает ошибку. Объявляю так:

procedure SConnect(Sender: TObject; Socket: TCustomWinSocket);
begin
end;

ClientSocket:=TClientSocket.Create(nil);
ClientSocket.OnConnect:=SConnect; < ошибка

← →
Digitman © (2003-09-24 12:59) [8]

> Vint45

понятия "процедура" и "процедурный метод класса" весьма различающиеся.

procedure TSomeClass.SConnect(Sender: TObject; Socket: TCustomWinSocket);
begin
end;

← →
Vint45 (2003-09-24 13:23) [9]

Хорошо, мне чтобы обработать событие, надо свой класс объявить?

← →
Alex Konshin © (2003-09-24 13:26) [10]

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

← →
Alex Konshin © (2003-09-24 13:27) [11]

Даже не просто объявить класс, но и создать объект этого класса.

← →
Vint45 (2003-09-24 13:30) [12]

Спасибо, буду знать

← →
Digitman © (2003-09-24 13:38) [13]

> Alex Konshin

> но и создать объект этого класса

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

← →
Alex Konshin © (2003-09-24 13:57) [14]

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

← →
Digitman © (2003-09-24 14:17) [15]

> Конечно, можно не создавать и сделать через приведения к
> TMethod

я это и имел ввиду
разумеется, на данном этапе познания "таинств" для автора это сущий геморрой)

← →
Vint45 (2003-09-24 15:25) [16]

События вроде перекрыл, но работает не так как надо.
Специально для Alex Konshin говорю, что я не цепляюсь за TClientSocket, меня заинтересовал вопрос как через консольное приложение, в котором не создан объект Application можно обрабатывать события. Кстати, по WinSock2 можете дать какие-нибудь ссылки? Буду премного благодарен.
Теперь о событиях в консоле.
Я перекрыл событие OnConnect. Переход в него не переходит, если в программе не делать задержку. Например с помощью ShowMessage, в этом случае событие обрабатывается. Вроде это и понятно, так как консольная программа, после того как выполнит все команды, заканчивает свое действие и событие не успевает наступить. В таком случае мне для обработки событий нужно создавать свой какой-то цикл, в котором дожидаться наступления события или есть что-то еще? Мне просто интересно, потому как буду пользоваться все-таки WinSock2.

> Переход в него не переходит, если в программе не делать
> задержку.

установи перед ClientSocket.Open св-во ClientSocket.ClientType := ctBlocking

и будет тебе счастье

и не спрашивай - почему ...

ответ - во внимательном изучении спецификации Winsock и предельно четком понимании механизма асинхронных событий Windows

А ещё кто-то говорил, что если нет цикла обработки сообщений (Application.Run, Application.ProcessMessages, на худой конец просто апишный цикл GetMessage-TranslateMessage-DispatchMessage), то большинство VCL компонентов работать не будут...
Поэтому в консольном приложении надо его (цикл) создавать.
Или я чего-то не так понял?

> Или я чего-то не так понял?

Все правильно понял. Только T(Client/Server)Socket могут в принципе обойтись и без этого. См. Digitman.

← →
Vint45 (2003-09-24 16:57) [20]

Ага, вроде получилось и принять данные и получить их.

Самая полная документация по Winsock2 в MSDN: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/windows_sockets_start_page_2.asp
На худой конец сойдет sock2.hlp, который идет в поставке Delphi версии >=5. Ладно, я так понял ты пока еще топриком плаваешь, поэтому пока попользуй свой любимый TClientSocket, потом когда окрепнешь - нальем воду и научим плавать по-настоящему.
Успехов.

Использование сокета(клиента) в консольном приложении Найти похожие ветки