This is made available as an event of the COM object, and I can't see any way of getting it.

Can someone confirm that there is no way to respond to events.

Depends on the object. We know for sure that KiXtart COM doesn't support ActiveX event handling in any way. So having said that, most times an object will provide state properties that you can loop against. For example, IE has navigation state change events, but it also provides a readystate property that non-event-aware scripting languages can query ... so again, depends on the object ...

What object is this ? Playing with the HTTP driver-control ?

-Shawn

I can create a listener and telnet to it, but the socket state never changes from "listening". When the object hears my incoming telnet session it will trigger a "ConnectionRequest" event which passes a requestID.

While waiting the socket state should change to "ConnectionPending", but it doesn't. I guess that the inability to raise events is causing this, but I'm not sure. If I attempt to accept the connection anyway I get a "socket is not in the correct state" error.

I'm quite happy that the two are talking - as soon as I quit the listener the telnet session from the remote machine is also killed.

I'd write my own library which didn't depend on events, but I'm a *nix "C" coder and I get nervous at the sight of object orientation, and positively ill when confronted with non linear program control, so I'm struggling.

I've been looking at the idispatch stuff to see if I can find the events in a stack somewhere and handle them manually, but it has given me a headach so I'm going to have a lie-down.

Perhaps a facility to register Kix functions as handlers for events is the best way to go. Sounds like an awful lot of work though.

In case I'm missing something, here is a simple example of the code I was playing with:

code:

---

break on
$oSocket = CreateObject("mswinsock.winsock")
if @error <> 0 "Cannot create socket object:" ? @error " / " @serror ?  exit 1 endif
"My Name: " $oSocket.LocalHostName ?	; Who am i
"My IP: " $oSocket.LocalIP ?		; Where am i
$oSocket.Protocol=0			; Equates to TCP
$oSocket.LocalPort=10000		; Any old non-restricted socket
$oSocket.RemotePort=0			; We are a listener
$oSocket.Listen				; Start Listening
if @error <> 0 @error " / " @serror ?  endif
while $cKeyPress <> "q"
	?
	"Socket Information: " ?
	"   Status: " $oSocket.State ?
	"   RemoteHost: " $oSocket.RemoteHost ?
	"   RemoteHostIP: " $oSocket.RemoteHostIP ?
	"   RemotePort: " $oSocket.RemotePort ?
	"   BytesReceived: " $oSocket.BytesReceived ?
	"   SocketHandle: " $oSocket.SocketHandle ?
	"     Hit a key to refresh, 'q' to exit: " get $cKeyPress
loop
$oSocket=0

---

If you run the script (and have the winsock control!) you will start a listener on port 10000. You will see that the status is "2", which is sckListening. You can now telnet to port 10000. The status should change to "3", sckConnectionPending but it doesn't.

If you drop the listener (hit 'q') you will see that the telnet session is forced closed as well.

I'm a bit of a COM numpty, so any advice / direction would be appreciated.

I do not know why your com object is not working... have you tried using VBscript to do the same results?

I too have been looking for a way to script low level tcpip functions, but I have not found a way to do so. I never would have thought of creating my own library!

Bryce

[ 25 September 2001: Message edited by: Bryce ]

ok - i just ported Richards script to VB and it works like a charm ... here's that ...

code:

---

Private Sub Form_Load()
   
    winsock.Protocol = 0
    winsock.LocalPort = 80
    winsock.RemotePort = 0
    winsock.Listen
        
End Sub
Private Sub winsock_ConnectionRequest(ByVal requestID As Long)
    MsgBox ("Hello, World")
    
End Sub

---

mswinsock is more than an Automation object - it's an OCX (an ActiveX control in the pure sense of the term) ... this means that it must be hosted by an ActiveX control container like VB - but WSH/VBScript/JScript can also host controls and respond to events (it's just not documented very well) ... but in terms of KiXtart, I think we're screwed ...

-Shawn

cscript test.vbs

code:

---

Dim oSocket

Set oSocket = WScript.CreateObject("mswinsock.winsock", "oSocket_")

oSocket.Protocol=0
oSocket.LocalPort=80
oSocket.RemotePort=0
oSocket.Listen				

WScript.Echo "Sleeping for ten seconds ..."

WScript.Sleep 10000

sub oSocket_ConnectionRequest(requestID)
 msgbox "Connection Request Received !!!"
end sub

---

This is fun !

-Shawn

[ 25 September 2001: Message edited by: Shawn ]

Bryce

the freeware version might be interesting!

Bryce

I have a working solution using the 32-bit Catalyst control, and I'll drop a sample here sometime tomorrow once I've cleaned it up. Prepare to be slightly bemused.

I didn't have any luck with the 16 bit version - it just kept telling me that the class wasn't registered, even after I manually registered it. I wanted to used the 16 bit version because the docs implied that it was designed to run in a non-event driven environment.

It's just a shame that you need a 5MB download to get it working.

Shawn, as our resident COM/OLE guru do you have any pointers to creating basic DLL's where I can plug in some 'C' code to do the job in the same vein as the kixlib32 code?

Yesiree bob - the best (THE BEST) tool for creating COM (Automation) objects (ala kixlib32) is to use Visual Studio 6 C++ (obviously) and the ATL (ActiveX Template Library) ... ATL IS NOT MFC (thank god) and doesn't require the use of the MFC runtimes ... (did I mention that I hate MFC ?!!!)

When starting a new project, select the ATL COM AppWizard, give your component a name and ATL will create a bare-bones COM component server for you ... Adding ATL classes (the objects themselves) is a snap, adding methods and properties is easy as well ... the wizard will automatically create your prototypes and your insert your function wrappers. This is were you can plug-in your code ...

The only thing the ATL wizard does not do (very well) is allow you to specify your method parameters. To do this, you need to learn IDL (Interface Definition Language) but with COM, it's good to know that anyway ... plus you only need to learn the bit that relates to specifying method parms ...

Would be glad to assist you in anyway I can ... maybe we can work-up a small project and step through it together (offline) ...

-Shawn