Since the Serial protocol is byte oriented... it always must send a full byte of data; it can not send less or more at one time. If it needs to send two bytes, it sends one and then the other... serially, hence the name. A byte is 8 binary digits (0 or 1). A byte can also be represented as two hexidecimal digits (0 through F). So the maximum value that can be stored in a byte is 11111111 in binary, 255 in decimal, FF in Hex, or the character "ÿ" in ASCII. (a "y" with an umlat).
Check out the ASCII table at http://www.ascii-code.com/
. You'll notice that the values of the characters range from (Decimal) 0 to 255. The maximum ASCII value fits perfectly into a single byte. I'm sure the gods who created the first ASCII table did this on purpose. Then the UTF-8 gods came and destroyed them. (haha, that was a joke)
Since PCs use the ASCII character set, and the Serial protocol is byte-oriented, naturally most PC programs interpret Serial data as ASCII. I'm sure that some programmer out there thought they were saving you a lot of trouble by doing that. I guess they assumed that Serial communication was generally going to be used for sending text (characters). On the Arduino side, however, you have the Serial.print() function which lets you specify if you want to transmit the BYTE, or DEC value which does the conversion to ASCII for you. The Serial.write() function does not... it always sends the BYTE value.
With all that said, there are two issues with your code:
1. You declared your buffer array as an integer... which is a two-byte data type. That'll cause significant issues if you try to send that over serial. It will probably succeed, but it will split all of your integers into two bytes each, and you'll need to re-assemble the values on the other end. It will also only send half as much as you thought you were sending... only 50 integers would get sent. This was already pointed out by PaulS, and looks like you've fixed that. Strings are just buffers of the char data type (which happens to be a single-byte) so that will work nicely.
2. The thing you need to remember is that the data type really matters. If your buffer array is declared as integer, setting buffer=65 sets two bytes:
Binary: 00000000 01000001
Hex: 00 41
Since the value is not greater than 11111111 binary or FF hex, the high byte is set to zero. The character represented by a zero, chr(0), is null, which usually behaves badly for programmers. It is not zero, it is literally, nothing. It will not be displayed, it takes up no space.
But if your buffer array is declared as BYTE, or char, then assigning buffer=65, you're only setting a single byte (This is equivalent to buffer='A').
So, the character (or ASCII value) of 65="A". When you transmit that across, PCs interpret that as ASCII, not as a byte. Most programs will let you use an asc(<character>) function to return the decimal value of the character, and a chr(<number>) function to give you the ASCII character from a decimal value.
A way you can get around this issue, is storing your numbers as characters (strings) and then parsing out the values on the PC end.
So if you want to send the sensor's value 1023, you store it in a string as "1023". When you send the character buffer (length 4) across the serial connection, it sends:
On the PC side, it will receive the string "1023" because it (usually) automatically assumes Serial data is ASCII. To re-assemble it to an integer value, you then parse the digits, or use a ValueOf(<string>) function like Java supplies.
Another way to deal with this issue is to use the map() function in your Arduino code. The map function allows you to map a value range to another range. So, you can convert your sensor values (0-1023) to a byte range (0-255). This way, you can simply save the values as bytes and send them across. Then tell the PC to use the ASCII value Asc() instead of the character! Of course, re-mapping the value range to a smaller one causes a loss of resolution. It just depends what you need.
A hack work around... quick and dirty... if you're just sending numbers 0 through 9, is to add decimal 48 to the integer value and save it as a byte.
0 +48 = 48. ASCII 48="0"
1 +48 = 49. ASCII 49="1"
2 +48 = 50. ASCII 50="2"
3 +48 = 51. ASCII 51="3"
4 +48 = 52. ASCII 52="4"
... you get the idea.