Whatever it is, I want my data! I really don''t want to read the whole string at once and parse it in a different function; why should it be that hard?

quote: Original post by Zipster
Whatever it is, I want my data! I really don''t want to read the whole string at once and parse it in a different function; why should it be that hard?

Frankly, because doing it in .DataArrival() that way is a piss-poor implementation. Slurp the whole thing into a string and parse the string in another procedure. Get out of .DataArrival as soon as possible so the socket can clean up and get ready for the next work Winsock has to do.

This also keeps your socket code VERY CLEAN if you find yourself using a transport other than Winsock at a later date. Writing a parser should be easy, and if it''s not, then your message structure should be revamped so that it''s easier to parse. You are not going to override .DataArrival to do what you want it to do without a LOT of voodoo.

------------------
-WarMage
...systems analysis ninja...

Why on God's Green Earth are you doing this in VB?

In the -1 case, it did _not assume a 8bit value. It may have sent the string "-1", hard to say with variant untypes.

Find a table of VB to C data types, it'll help - no it's neccessary for this sort of thing. A VB int is only 16bits.

Try using CStr("info") cast to force VB to use c style strings, OR when you dim the string, put a *255 after it (or however big you want it), and it will actually create a string of that size (not a b-string!).

Since VB6 is a STA only environment, winsock serializes everything through the message pump - which means your app must be pumping in order for you to receive winsock notifications.

Have you tried creating a type with the elements you want in it, and passing that to GetData?

quote:
Frankly, because doing it in .DataArrival() that way is a piss-poor implementation.

For a generic handler that would be a bad way to do it, but since the implementation tool is VB, there's no hope of a generic handler - every time you use winsock you will overload DataArrival.

quote:
Slurp the whole thing into a string and parse the string in another procedure

In VB how? No Pointer's man. Though you can cast... sorta

Edited by - Magmai Kai Holmlor on October 12, 2001 11:29:25 PM

I knew someone would ask why I''m doing it in VB, and frankly, that''s not my question. I already told you why, so how did this come up?

This isn''t going to be the most complicated program ever. All I want is some simple sending and recieving of data, and I am finding that really hard to do! I thought that having a nice WinSock control in VB would mean that there would be nice, easy functions to bind the socket and transfer data, but all I have are these two generic "one size fits all" functions that are turning into a real hastle to use. All this worrying about data type sizes, variant variables, etc... I might just be better off back in my console program! But I suppose I just have to read the whole shabang and parse it manually. Damn, I find that easier in C too!

quote:
and I am finding that really hard to do!

That''s because you''re pushing VB''s design specifications; if you want to that socket control and have it be easy, you need to send and receive plain strings - like the IRC protocol.

VB does not work with binary data very well at all. And drop&click controls rarely work the way you want them too, they''re protyping tools that get marketed as easy-to-use, ready-to-go programming.

Did you try making a type? VB may hanlde filling it for you...

I think I learned my lesson: don''t use VB for control! Hehe...no pun intended I did get what I wanted, by reading the whole thing into the string at once and parsing it later. But I always hated parsing and tried to get the control to do it for me, but oh well. Next time I''ll just use the WinAPI and regular C Winsock. I like that a lot better!

Mag, there are pointers in VB. It is undocumented but there is something called a StringPtr or something like that if I remember correctly. It is a bitch to use but it is there.

Next,

There are another alternative...

You could build a simple ATL COM DLL and that provides interfaces for your VB app. This way you can use C++ and the Winsock API natively. Using ATL makes building COM objects really easy.

After the DLL is built, just add it as a reference to your program. That way you get the best of both worlds.

Dire Wolf
www.digitalfiends.com

Edited by - Dire.Wolf on October 14, 2001 3:31:02 PM

And VarPtr

Binary manipulation in VB I''ve found is pretty similar to C++ with the main exception being the abscence of a bit shift, and the fact that the only unsigned type is the Byte. But both those things can be worked around, and I''m pretty sure the compiler optimises x * 2^n to being a bitshift anyway, so that is all good (although you also have to learn not to use the ^ operator for integers in VB since it is almost as slow as a variant )

How I would convert this code:

'' The name of the Winsock control is, *gasp* WinsockWith Winsock             .Bind 1010                     .RemoteHost = IP.Text ''IP is a textbox control             .RemotePort = Val(Port.Text) ''Another textbox control                 .SendData -1             .SendData "info"End With 

You could go for the simple method as Magmai suggested using a type:

Type udtMessage     HeaderBytes As Long     Message As String * 4     Terminator As ByteEnd Typeblah blah blahDim MyMessage As udtMessage''blah blah blahWith MyMessage .HeaderBytes = -1 .Message = "info" .Terminator = 0End With''blah blahWinSock.SendData MyMessage 

But since that isn''t very robust (doesn''t allow different sized messages), you could try instead making the udt more flexible:

Type udtMessage   HeaderBytes As Long   Body() As Byte   Terminator As ByteEnd TypeFunction CreateMessage(Body As String) As udtMessage   Dim i As Long      With CreateMessage      ReDim .Body(Len(Body) - 1)      For i = 1 to Len(Body)         .Body(i - 1) = Asc(Mid$(Body, i, 1))      Next      .HeaderBytes = -1      .Terminator = 0   End WithEnd Function 

And that would probably be a lot nicer. If you split up the packet like you were originally doing, then the server isn''t going to know how to handle it. Otherwise, you could bomb out a server by just sending it a 4 byte long (Not 0) message which would then mean the server is trying to keep track of all these differen possible commands.

Trying is the first step towards failure.

Mag, you can also define arguments with special modifiers ByRef and ByVal. Passing something ByRef is (I believe) generally the equivalent of passing a pointer to an object.

--------------
-WarMage
...burp...