HELP! with VFP and winsock control
Chris Erker
really do love this language and the OOP features it has available to it!!!
:)
Back in my old job I had to write a proof of concept of a tcp/ip client
server app in VB. So I basically typed in the Microsoft sample from the
MSDN help system and I had a tcp/ip chat program in about 10 minutes....
Now I am trying to get the same Microsoft's winsock tcp/ip client/server
sample to work in VFP but I have become stuck . I've stepped through the
code and it appears that even though the client form says its connecting
(the connect event fires), the connection never really goes through.
When I attempt to send a message to the Sever I get the following error:
"OLE IDispatch exception code 0 from Winsock. Wrong protocol or connection
state for the requested transaction or request."
The vfp project is simple enough. It contains 2 forms (1 server, 1 client).
Because the code is so simple I'll just paste it here... I hope I am just
missing something very simple but I've already spent 2 days working on this
with the same result... HELP!!!!!!!!!!!!!!! :)
-- Chris
************************************************************************
The program is started from a main.prg This is the code in that module.
DO FORM Forms\tcpServer
DO FORM Forms\tcpClient
READ EVENTS
************************************************************************
The server form is called frmServer and I have placed a Winsock control on
it called tcpServer.
INIT()
THIS.tcpServer.Protocol = 0 && tcp/ip protocol
THIS.tcpServer.LocalPort = 1001
THIS.tcpServer.Listen()
DESTROY()
CLEAR EVENTS
txtSendData.INTERACTIVECHANGE()
THISFORM.tcpServer.SendData(THIS.Value)
tcpServer.CONNECTIONREQUEST()
*** ActiveX Control Event ***
LPARAMETERS requestid
IF THIS.State <> 0 THEN
THIS.Accept(RequestID)
ENDIF
tcpServer.DATAARRIVAL()
*** ActiveX Control Event ***
LPARAMETERS bytestotal
LOCAL lcData
THIS.GetData(@lcData)
THISFORM.txtOutput.Value = lcData
************************************************************************
The client form is called frmClient and I have placed a Winsock control on
it called tcpClient.
INIT()
THIS.tcpClient.Protocol = 0 && TCP/IP
THIS.tcpClient.RemoteHost = '128.129.0.8'
THIS.tcpClient.RemotePort = 1001
THIS.tcpClient.Connect()
THIS.txtSendData.Enabled = .F.
txtSendData.INTERACTIVECHANGE()
THISFORM.tcpClient.SendData(THIS.Value)
tcpClient.CONNECT()
THISFORM.txtSendData.Enabled = .T.
tcpClient.DATAARRIVAL()
*** ActiveX Control Event ***
LPARAMETERS bytestotal
LOCAL lcData
THIS.GetData(@lcData)
THISFORM.txtOutput.Value = lcData
James Wieland
When you place a control on a form it will reside in an OLE Container. So
you need to reference the control as varname.object.property.
e.g. THIS.tcpServer.Object.Protocol = 0 && tcp/ip protocol
THIS.tcpServer.Object.LocalPort = 1001
etc...
Jim
"Chris Erker" <cerke...@hotmail.com> wrote in message
news:e0tu2$j9$GA....@cppssbbsa02.microsoft.com...
Reind Brackman
By the way, I use MABRY asyncsocket activex control for ease of use.
What control do you use?
James Wieland <jwie...@inav.net> wrote in message
news:O6mK8Us9$GA.276@cppssbbsa05...
Chris Erker
Thanks guys, that got me past my problem!!! :)
However now I am getting the same error message on the server form when it
goes to execute the following line:
tcpServer.CONNECTIONREQUEST()
*** ActiveX Control Event ***
LPARAMETERS requestid
IF THIS.object.State <> 0 THEN
THIS.object.Accept(RequestID) <========= THIS LINE
FAILS
ENDIF
I've been searching in a lot of spots for some answers to this and I
remember reading from someone basically saying that it is cheaper to buy the
$150 control than it is to spend even a day trying to make winsock work..
Well I'm well into Day 4. LOL!!! For me this is turning into a grudge match!
:)
I appreciate everyone's help on this, and I hope someone can point out the
error of my ways! (Besides being to stubborn!) :)
-- Chris
"Reind Brackman" <b...@euronet.nl> wrote in message
news:8lmfu5$2kd5$1...@buty.wanadoo.nl...
Torsten Kühnel
try to call the accept-method of a second control which is in state 0.
many programs use one "listening" socket, which then passes requests for
connections to new created objects, so that the
listening port stays free for further requests.
The second control does not need to be initialized, it will choose a free port
by itself and identify the client-request by the requestid (i think this happens
in the OS sockets-part) and connects to it.
One question: Do you want to transfer small packets (100-1000 bytes) of data
between the controls, or are you interested in transferring
bigger things like whole files ? i did not get any kind of flow control
integrated in my programs using the winsock.control under vfp.
when i call object.senddata to transfer data, the control immediatly returns,
regardless of the fact if the data is real send or only buffered.
the sendcomplete-event is not called everytime a packet is sent, so sending the
next packet trough this event is not a solution.
Please tell your experience, here or by email.
Torsten Kühnel
Chris Erker schrieb:
Chris Erker
Hi Torsten,
Creating a second control on the server form DID in fact work. Let me take a
moment to thank you and all the people who responded privately to tell me
that. After the fact when I was reading through MSDN it DOES mention that
you need a second winsock control for the server, but in a round-about
way... Right now I am having an issue of trying to shut down the
application. If I close the Client Form first, then VFP seems to hang...
Once I can get around that (or if anyone has any ideas as to Why that is
happeneing) I am going to post my full converted sample app to the
newsgroup. (I would have loved to have had that when I first started, and
the VB sample just doesn't cut it...)
Torsten, I'm not sure I understand what you mean with SendComplete.
According to the docs, SendComplete should only fire after the send
operation is done... I would take that to mean that all the data should be
sent to the client by the time this event fires... Could you explain what
you mean a bit more?
Thanks again for everybody's help on this!! :)
-- Chris
"Torsten Kühnel" <Torsten...@t-online.de> wrote in message
news:3981F448...@t-online.de...