Winsock, changing data types

[invitro]

Well, i have a client and a server

client sends binary or string data

in the server, i have under the getdata function


dim myData as string
winsock1.getdata myData

however, if the client is sending a byte... this will cause a problem?

how can i interprit what is coming from the client before it lands in a variable?

the purpose is to use 1 winsock control... any ideas?
does it even matter if the incoming data is stored as a string?

[BuggyProgrammer]

shouldn't you know whether it will be binary or ascii? you could just always accept it in byte() aray, then check if the data is suppose to be binary or not.

[azteched]

Think about it this way. At the most basic level, the data sent is just a load of bits, which is just a load of bytes. Winsock does not attach any sort of "data type" metadata when your data gets put on the wire - the data type thing is a purely artificial thing.

IMO this is poor design from the winsock control, but that's another issue.

Since VB uses BSTR as its string type, strings can have embedded nulls, so a byte array and a string can both be used for getting the data.

Uh, anyway - receive the data in the most convenient form, you can always convert either way (though it's expensive).

[invitro]

Well, the reason why i asked this question is for the fact that my Client sends a picture to the server

now, when I get the picture... its very distorted and fuzzy
I recieve that data as a string, determine whether it is suppose to be just string data or if its binary data for the file...

So I thought the problem was in recieving the data as string... but since it does not matter, it looks like my problem is somewhere else.

Thanks

PS: no i wont always konw if its ascii, since the same winsock control is used to send files AND simple chat messages and other such things, so i wont know if the user wants to use binary or ascii

[BuggyProgrammer]

Originally posted by azteched
Since VB uses BSTR as its string type, strings can have embedded nulls, so a byte array and a string can both be used for getting the data.

Well for me when I do

?asc(chr(192))

in the immediate pane, I get 0. Strings can't hold all 0 to 255. Much less than 255 characters. If you are going to work with extended ascii as well, then you use byte.

[invitro]

Originally posted by BuggyProgrammer
Well for me when I do

?asc(chr(192))

in the immediate pane, I get 0. Strings can't hold all 0 to 255. Much less than 255 characters. If you are going to work with extended ascii as well, then you use byte.

well i fixed my issue... i just used a string to pass the data and it seems to work. However, im not sure what you mean here.... extended ascii? can strings not support 255 chars?

mind elaborating on that a bit, im curious

[azteched]

Originally posted by BuggyProgrammer
Well for me when I do

?asc(chr(192))

in the immediate pane, I get 0. Strings can't hold all 0 to 255. Much less than 255 characters. If you are going to work with extended ascii as well, then you use byte.

Strings are stored in RAM - fundamentally all any data is, is lots of bits. Data types are "artificial", if you catch my drift.

You can hold any data in a string of sufficient length, just as you can hold any data in a array of anything of sufficient length, because it's all just a load of bits stored in RAM.

The issue of represnting characters on the screen is entirely separate; that's the issue you're bringing up.

[BuggyProgrammer]

Originally posted by azteched
Strings are stored in RAM - fundamentally all any data is, is lots of bits. Data types are "artificial", if you catch my drift.

You can hold any data in a string of sufficient length, just as you can hold any data in a array of anything of sufficient length, because it's all just a load of bits stored in RAM.

The issue of represnting characters on the screen is entirely separate; that's the issue you're bringing up.

We are talking about the String datatype being able to HOLD all the characters, which is evidently not possible.

Take a look at these two cases:

Dim bytes(0) As Byte
Dim strings As String
 
    bytes(0) = 192
    strings = Chr(192)
 
Open "C:\test.bin" For Binary As #1
    Put #1, , bytes
Close #1
 
Open "C:\another.bin" For Binary As #1
    Put #1, , strings
Close #1

Looking in a Hex Editor, for bytes() we get
C000010000
which equals to 192

for Strings, we get
00
which equals to 0

So how would it be possible for strings to hold eveything? It isn't.

[BuggyProgrammer]

Originally posted by azteched
Strings are stored in RAM - fundamentally all any data is, is lots of bits. Data types are "artificial", if you catch my drift.

You can hold any data in a string of sufficient length, just as you can hold any data in a array of anything of sufficient length, because it's all just a load of bits stored in RAM.

The issue of represnting characters on the screen is entirely separate; that's the issue you're bringing up.

Oh yeh I mistyped Characters. I meant character codes, like 1 to 255.

[azteched]

Memory is memory. Strings are stored in memory. Byte types are stored in memory. There's no distinction at the fundamental level.

[BuggyProgrammer]

Originally posted by azteched
Memory is memory. Strings are stored in memory. Byte types are stored in memory. There's no distinction at the fundamental level.

So what? I don't care if it is stored in memory or whatever. String datatypes can't hold the entire ascii table. Understand? You keep talking about something else.

You first said

so a byte array and a string can both be used for getting the data.

which is false, because using a String WILL corrupt the data. You just, for some reason, started talking about memory, which really has nothing to do with the fact that the string will coruppt the data.

[azteched]

As I haven't used VB winsock in ages, you're very likely to be right

Your posts did give me the impression that you seemed to think that different datatypes were somehow differently stored at the physical level - if that wasn't the case then ignore.