.76 screws up TCPRecv()!

[VicTT]

I've updated to .76, and re-started work on my Trivia bot script..Since it was still in alpha stage, I was logging everything that was received, and transmitted over the socket..To my surprise, in a few seconds, my HDD filled up with a 100 MB file(yea..My HDD is usually almost full anyway)..I checked the file..It was all full of nulls..basicly, every time a TCPRecv fails, a NULL is returned..and that is EVIL!I'm not sure I even get why Binary() was ever introduced(can't find any specs to it in the helpfile)..The devs always talked about not breaking scripts through further changes..but they just broke the hell out of how TCP functions work..I've reverted to .75 for now..Devs..ca you please explain the use of all this?Binary, screwing up my script, no specs to the Binary func..I'm just not seeing the master plan here..

Edited September 25, 2005 by VicTT

[jefhal]

From the installation program splash screen:

---------------------------

AutoIt v3.1.1.76 (beta) Setup

---------------------------

Please note, this is BETA software. Any and all features are likely to change and you

may need to update your scripts when AutoIt is officially released.

Use beta links in the Startup menu. Enjoy!!!

---------------------------

OK

---------------------------

[VicTT]

It wasn't supposed to sound as if I was criticising(too badly)..I was pointing out, though, that your quest for backwards-compatibility didn't work out in the case of TCPRecv()....I know I should have posted this in the Bugs Forum but I was hoping that someone could give me a work-around solution..Sorry for sounding rude..It's just the first time I have to revert to a previous beta because of (bad coding?) non-backward-compatibility..Sorry again..

Basicly, I'm asking "What happens when the socket ACTUALLY receives a null character?How do I differentiate between the socket receiving nothing, and the socket receiving a null character?"..If this was a feature, you should have the answer to this..If this is a bug, then I agree I posted on the wrong forum..

[MSLx Fanboy]

Will TCPRecv not return an @error?

The helpfile lists on error results for a reason...

Edited September 25, 2005 by MSLx Fanboy

[Valik]

FYI: What do we have to maintain backwards compatibility with? The last stable release was 3.1.1.0. Check it out and you'll see there are no TCP functions so. Therefore, there is nothing to maintain backwards compatibility with.

[MrSpacely]

Some people wanted binary support, me included because its really handy for storing files with 0 char (NULL) and reading files with NULL in it

also good they added this for tcp function

So why well its really handy and its actually not possible to read files with NULL chars in a fast way without this support.

Altough I haven't tried the binary things yet thats on my happy list.

And yes its beta but I think its better then the stable version.

Several reasons 3.1.1 crashed on me several times while beta worked fine (with standard functions) beta has much more features

So i use beta and just test a lot. (testing should be done anyway)

[jpm]

Stay tune you will have back the TCPRecv working in 3.1.1.77 the TCPRecv, TCPSend are in regression in 3.1.1.76.

Sorry about that I should have test more carefully.

Edit: Fixed in 3.1.1.77

Edited September 26, 2005 by jpm