Shoutbox

I'm working on a little plugin, just to toy around and kill boredom, but I've hit a bug. For what I want to achieve, I need to have a method to send a couple of integers to the person I'm talking too. I figure that I can do this somehow using notification codes, but am unsure of the syntax required. Can anyone shed light on this issue for me? Thank you.

Note: I'm using VB6, FYI.

Whatever you send, you must send it as a string (since sResult is defined as a string in the plugin API in VB in the ParseCommand procedure)... So convert your integers to a string and use that as the sResult variable to send back...

You could use the poor-mans method:
your integers:
I1 = 1234
I2 = -4789
I3 = 45
the string you send: "1234,-4789,45"
eg: sResult = Chr$(nCCNotify) & "smvpg" & "1234,-4789,45"

Using the ReceiveNotify procedure, sText will contain "1234,-4789,45". Thus, you interpret it again by splitting it up, using the comma as delimeter.


Or the smart advanced method:
(allows you to send/recieve _a lot_ of integers! Per character, you normally could send, you have 1 integer. Because a character is actually always 2 bytes, the same as an integer...)

your integers are the same as above,

Since an integer (or whatever) is stored as sequences of bytes in memory and strings are stored just the same way, you can interpret each integer as a wide character of a string. Because an integer consist of two bytes and a wide string character also consist of two bytes. Thus the string, using the example integers above, would consist of only 3 wide characters (=6 bytes, this in contrast to the first method where your string consists of 26 bytes): ChrW$(1234) & ChrW$(-4789) & ChrW$(45).
eg: sResult = Chr$(nCCNotify) & "smvpg" & ChrW$(1234) & ChrW$(-4789) & ChrW$(45)

Using the ReceiveNotify procedure, sText will contain ChrW$(1234) & ChrW$(-4789) & ChrW$(45). Thus, you interpret it again by getting the wide characters one by one:
Dim I as Integer
For T=1 To Len(therecievedstring)
  I = AscW(Mid$(therecievedstring, T, 1))
Next T

quote:

---

Originally posted by CookieRevised
Or the smart advanced method:
(allows you to send/recieve _a lot_ of integers! Per character, you normally could send, you have 1 integer. Because a character is actually always 2 bytes, the same as an integer...)

your integers are the same as above,

Since an integer (or whatever) is stored as sequences of bytes in memory and strings are stored just the same way, you can interpret each integer as a wide character of a string. Because an integer consist of two bytes and a wide string character also consist of two bytes. Thus the string, using the example integers above, would consist of only 3 wide characters (=6 bytes, this in contrast to the first method where your string consists of 26 bytes): ChrW$(1234) & ChrW$(-4789) & ChrW$(45).
eg: sResult = Chr$(nCCNotify) & "smvpg" & ChrW$(1234) & ChrW$(-4789) & ChrW$(45)

Using the ReceiveNotify procedure, sText will contain ChrW$(1234) & ChrW$(-4789) & ChrW$(45). Thus, you interpret it again by getting the wide characters one by one:
Dim I as Integer
For T=1 To Len(therecievedstring)
  I = AscW(Mid$(therecievedstring, T, 1))
Next T

---

i wouldn't do that because there may be problems with integers which one of their bytes is zero... that would be the NUL character used to mark the end of a string and that could give problems because messenger would only send the first bytes up to the first zero (NUL) byte.

For example:

code:

---

'......
Dim I1 as Integer
Dim I2 as Integer
Dim I3 as Integer
'.......
I1 = 1234
I2 = 0
I3 = 4500
'.....
sResult = Chr$(nCCNotify) & "smvpg" & ChrW$(I1) & ChrW$(I2) & ChrW$(I3)
' ^ that would create a string that has the notify code, the letters "smvpg",
' two bytes (&H4 and &HD2) and then two bytes set to zero
' and finally two bytes more (&H11 adn &H94)
' but the first byte set to zero (coming from I2) will indicate end of string
' (remember that in C, strings end in '\0')
' That would cause problems when sending the message

---

In fact, if the integers are in the range 0..255 or if they are a multiple of 256 (including negative multiples) that issue would happen.


As a work arround for that, maybe the best way to send the numbers would be in hexadecimal format...

The problem with these methods is that I want to try and avoid sending any data into the chat window - wanna keep things neat and tidy, don't want to throw data around in chat. Although, if there's no other way, looks like I'll have too.

Oh, and a note: the integers wouldn't be sent as integers, they'd be sent as a string, by default (sending data from the command arguments). The conversion to integer will happen after the person receives the data.

quote:

---

Originally posted by Heffy
The problem with these methods is that I want to try and avoid sending any data into the chat window - wanna keep things neat and tidy, don't want to throw data around in chat. Although, if there's no other way, looks like I'll have too.

---

no, there is no other way... you always have to use the chat window to send data between your pluging and your contact's plugin.

quote:

---

Originally posted by Choli

quote:

---

Originally posted by Heffy
The problem with these methods is that I want to try and avoid sending any data into the chat window - wanna keep things neat and tidy, don't want to throw data around in chat. Although, if there's no other way, looks like I'll have too.

---

no, there is no other way... you always have to use the chat window to send data between your pluging and your contact's plugin.

---

Obviously, lol. I kinda meant more like as in without actually sending messages, so we don't have needless text filling up the screen, which is not cool.

quote:

---

Originally posted by Heffy
Oh, and a note: the integers wouldn't be sent as integers, they'd be sent as a string, by default (sending data from the command arguments). The conversion to integer will happen after the person receives the data.

---

yes, that's what I was saying in the first place

quote:

---

Originally posted by Choli
i wouldn't do that because there may be problems with integers which one of their bytes is zero... that would be the NUL character used to mark the end of a string and that could give problems because messenger would only send the first bytes up to the first zero (NUL) byte.

For example:

code:

---

'......
Dim I1 as Integer
Dim I2 as Integer
Dim I3 as Integer
'.......
I1 = 1234
I2 = 0
I3 = 4500
'.....
sResult = Chr$(nCCNotify) & "smvpg" & ChrW$(I1) & ChrW$(I2) & ChrW$(I3)
' ^ that would create a string that has the notify code, the letters "smvpg",
' two bytes (&H4 and &HD2) and then two bytes set to zero
' and finally two bytes more (&H11 adn &H94)
' but the first byte set to zero (coming from I2) will indicate end of string
' (remember that in C, strings end in '\0')
' That would cause problems when sending the message

---

In fact, if the integers are in the range 0..255 or if they are a multiple of 256 (including negative multiples) that issue would happen.

---

Yeah, didn't think of that....  although it would only happen when the integer is 0, because text like that is unicode and thus each character is read in pairs of two bytes. So in the pair of 0x45 0x00, the 0x00 isn't an end of string marker. The end of string marker in unicode consists of a 0 word (integer value 0), not a 0 byte. Or so it should be... didn't tested this though...

quote:

---

Originally posted by Choli
As a work arround for that, maybe the best way to send the numbers would be in hexadecimal format...

---

yup, or the first method I mentioned. Well, actually those two are the same, you both send the numbers/digits as literal characters. But with the hexadecimal style you could send more integers at once...

(thinking of it, you could make your base 36 and use all the letters of the alphabeth and thus sending even more integers... or even an higher base using other ascii characters )

quote:

---

Originally posted by CookieRevised
Yeah, didn't think of that....  although it would only happen when the integer is 0, because text like that is unicode and thus each character is read in pairs of two bytes. So in the pair of 0x45 0x00, the 0x00 isn't an end of string marker. The end of string marker in unicode consists of a 0 word (integer value 0), not a 0 byte. Or so it should be... didn't tested this though...

---

true, but i said that because i wasn't sure about if the messages are sent as unicode (16 bits NUL terminator) or as ascii (usual 8 bits NUL)

quote:

---

Originally posted by CookieRevised
yup, or the first method I mentioned. Well, actually those two are the same, you both send the numbers/digits as literal characters. But with the hexadecimal style you could send more integers at once...

(thinking of it, you could make your base 36 and use all the letters of the alphabeth and thus sending even more integers... or even an higher base using other ascii characters )

---

i thought in that (base 36 or more) but i don't think it's worth it... only for a very few integers you would be able to send less characters than using hexadecimal