Esta clase, a mi modo de ver, se puede mejorar en el lado cliente.
Supongamos el caso en que establecemos una conexion del lado del cliente,
Bueno, si eso es ejecutado, al cabo del rato, salta el evento ONCONNECT, pero , si no tenemos escuchando ningun servidor en la ip correspondiente.
驴 Y que nos dice esto ? Que estamos conectado, lo cual no es cierto, pues SI NO EXISTE SERVIDOR, no podemos conectar, pero a煤n y asi, nos indica que estamos conectados, entonces, 驴 que esta mal ?
Bueno, realmente, seg煤n el api de windows, con los sockets asincr贸nicos, que son los que nos brinda Fivewin, el funcionamiento es correcto, es decir, el control pasa por el evento ONCONNECT en la clase TSocket, o a trav茅s del codeblock a nuestro disposici贸n, bConnect.
El problema radica es que se produzca esto NO SIGNIFICA QUE ESTEMOS CONECTADOS!, para ello, necesitamos consultar el numero de error, que nos brinda ;
Ese nErrorCode TIENE que ser enviado al codeblock de evaluaci贸n, para poder de esta manera, el disponer de que es lo que ha pasado exactamente, porque la funcion WsaGetLastError(), no garantiza en este caso, que sea el error correcto que te informe.
Asi, se deber铆a de modificar la clase TSocket en estos puntos:
Se recibe el nErrorCode y se envia al codeblock
2.- En el method HandleEvent(), observamos como pasamos nErrocode.
Con esto retoques a la clase, ya podemos determinar en nuestro c贸digo que es lo que puede estar fallando en la conexion, quedando asi;
Ahora SI QUE PODEMOS DETERMINAR si estamos o no correctamente conectado.
Antonio, 驴 crees que es posible meter esta mejora ? Tambi茅n se podria hacer lo mismo para los otros eventos, he explicado este pues es con el que he tenido que pelearme esta tarde.
Ademas, me he percatado de una cosa muy curiosa, ::nTimeOut,
驴 donde se hace uso de esto , y realmente se usa ?
Mirar茅 ma帽ana m谩s sobre esto.
Supongamos el caso en que establecemos una conexion del lado del cliente,
oSockClient := TSocket():New( 2000 )
oSocketClient:bConnect = { || MyConnect() }
oSocketClient:bRead = { | oSocket | OnRead( oSocket ) }
oSocketClient:bClose = { || MsgInfo( "disconnected!" ) }
oSocketClient:Connect( "localhost" )
STATIC FUNCTION MyConnect()
oMemo:Append( "CONECTADO" )
RETURN NILBueno, si eso es ejecutado, al cabo del rato, salta el evento ONCONNECT, pero , si no tenemos escuchando ningun servidor en la ip correspondiente.
驴 Y que nos dice esto ? Que estamos conectado, lo cual no es cierto, pues SI NO EXISTE SERVIDOR, no podemos conectar, pero a煤n y asi, nos indica que estamos conectados, entonces, 驴 que esta mal ?
Bueno, realmente, seg煤n el api de windows, con los sockets asincr贸nicos, que son los que nos brinda Fivewin, el funcionamiento es correcto, es decir, el control pasa por el evento ONCONNECT en la clase TSocket, o a trav茅s del codeblock a nuestro disposici贸n, bConnect.
El problema radica es que se produzca esto NO SIGNIFICA QUE ESTEMOS CONECTADOS!, para ello, necesitamos consultar el numero de error, que nos brinda ;
METHOD HandleEvent( nSocket, nOperation, nErrorCode ) CLASS TSocketEse nErrorCode TIENE que ser enviado al codeblock de evaluaci贸n, para poder de esta manera, el disponer de que es lo que ha pasado exactamente, porque la funcion WsaGetLastError(), no garantiza en este caso, que sea el error correcto que te informe.
Asi, se deber铆a de modificar la clase TSocket en estos puntos:
Se recibe el nErrorCode y se envia al codeblock
METHOD OnConnect( nErrorCode ) INLINE If( ::bConnect != nil, Eval( ::bConnect, Self, nErrorCode ),)2.- En el method HandleEvent(), observamos como pasamos nErrocode.
case nOperation == FD_CONNECT
if ::lDebug .and. ! Empty( ::cLogFile )
LogFile( ::cLogFile, { "Connect",;
"Socket handle:" + Str( nSocket ) } )
endif
oSocket:OnConnect( nErrorCode ) // Aqui.....Con esto retoques a la clase, ya podemos determinar en nuestro c贸digo que es lo que puede estar fallando en la conexion, quedando asi;
oSocketClient:bConnect = { |o,nErrorCode| MyConnect( nErrorCode ) }
STATIC FUNCTION MyConnect( nErrorCode )
if nErrorCode == 0
oMemo:Append( Time()+ "-->Cliente iniciado en [ " +cIp + ":"+str( nPort, 5 ) + " ]" + CRLF )
else
oMemo:Append( "Error conexion..." + Str( nErrorCode ) +CRLF )
endif
RETURN NILAhora SI QUE PODEMOS DETERMINAR si estamos o no correctamente conectado.
Antonio, 驴 crees que es posible meter esta mejora ? Tambi茅n se podria hacer lo mismo para los otros eventos, he explicado este pues es con el que he tenido que pelearme esta tarde.
Ademas, me he percatado de una cosa muy curiosa, ::nTimeOut,
驴 donde se hace uso de esto , y realmente se usa ?
Mirar茅 ma帽ana m谩s sobre esto.
Saludos
Rafa Carmona ( rafa.thefullARROBAgmail.com___quitalineas__)
Rafa Carmona ( rafa.thefullARROBAgmail.com___quitalineas__)
, mostrar un dialogo no wait por ejemplo, y cuando salte el evento del OnConnect(), pues matar ese dialogo, etc... , la imaginaci贸n al poder