Spht told me just to do:

[code]
Inet1.Execute "http://pic3.piczo.com/go/shoutbox?sb=158486&sbo=206585&shoutername=hmm&text=hmm"
[/code]

That doesn't seem to be working. Anybody got ANY ideas how to post in a piczo shoutbox? I packetlogged it, but spht said that the Inet way was the easiest.

Thanks in advance!

What is piczo?

http://www.piczo.com

Some shit website maker. I just want to make a bot so i can auto post in some (and spam some maybe?).

[quote author=Saphire link=topic=13598.msg138679#msg138679 date=1135127706]
http://www.piczo.com

Some shit website maker. I just want to make a bot so i can auto post in some (and spam some maybe?).
[/quote]

Any example piczo sites with a shoutbox?

http://wotyasay.piczo.com/?cr=3&rfm=y

(Warning: The SITE sucks cock.)

The source code, in the form's method is 'POST'. Therefore it sends the data to the next page opposed to sending it in the title bar (something=value) which is 'GET'.

I don't exactly know the format browser's use to send the data. Though you'll have to look it up in order to post messages in that shoutbox.

Hmm i see. I think i'll do a little more research on it, if not i'll just leave it. Thanks for all help at the moment people!

It's going to be something like:

[code]
Inet1.Execute "http://pic3.piczo.com/go/shoutbox", "POST", "sb=158486&sbo=206585&shoutername=hmm&text=hmm"
[/code]

IIRC, .OpenURL is used for returning information whereas .Execute just sends it (which is much more efficient/faster).

[quote author=dxoigmn link=topic=13598.msg138696#msg138696 date=1135134690]
It's going to be something like:

[code]
Inet1.Execute "http://pic3.piczo.com/go/shoutbox", "POST", "sb=158486&sbo=206585&shoutername=hmm&text=hmm"
[/code]
[/quote]

That didn't work? :-/ And i've tried other ways and none work. Hm :/

[code]wget http://pic3.piczo.com/go/shout --post-data="sb=444952&sbo=558902&shoutername=Me&text=Cool!"[/code]

That worked, so the string format was OK, but the target url was wrong...

You'll want to read up about the HTTP POST method and then use a socket.  The Inet control is possibly one of the worst controls ever made.

[quote author=rabbit link=topic=13598.msg138746#msg138746 date=1135177542]
The Inet control is possibly one of the worst controls ever made.
[/quote]

Why?

You can tell it to halt (.Cancel, I think), but it actually doesn't, and if you try to use .Execute or .OpenURL while it's doing something it errors out, and if you don't handle the error, your program crashes.  A Socket is just so much easier to use for something like this.

Usually in any program if you have an error and u dont handle it, the program crashes....

But since it's a control, you can't go and change the code to fix the error.

[quote author=rabbit link=topic=13598.msg138890#msg138890 date=1135286319]
But since it's a control, you can't go and change the code to fix the error.
[/quote]

It is meant to be handled...

I prefer to fix my errors, not make them easier on the eyes.

[quote author=rabbit link=topic=13598.msg139001#msg139001 date=1135352085]
I prefer to fix my errors, not make them easier on the eyes.
[/quote]

You are wrong in this case. There are many errors that can not be fixed by the programmer. You absolutely MUST handle errors in your program. How are you as a programmer going to fix the error of user not being connected to the internet? How are you as a programmer going to fix the error of user's hard drive being full? Error handling is vital.

Yes, but in the case of a control crashing because it doesn't check its own connection state before attempting to connect (again, without disconnecting), well...that's just stupid.

[quote author=rabbit link=topic=13598.msg139087#msg139087 date=1135390666]
Yes, but in the case of a control crashing because it doesn't check its own connection state before attempting to connect (again, without disconnecting), well...that's just stupid.
[/quote]

You need error handling for the control either way. And one might consider the programmer telling the control to connect again without disconnecting.. stupid! I find it quite reasonable of a control to raise an error if you tell it to do something that you should not.

I agree with Adron, instead of making the Programmer not have to worry about them the control should enforce the good programming habbits he should already have.

[quote author=rabbit link=topic=13598.msg139087#msg139087 date=1135390666]
Yes, but in the case of a control crashing because it doesn't check its own connection state before attempting to connect (again, without disconnecting), well...that's just stupid.
[/quote]

It does exactly what you told it to! Just build checks and error handling into your code (Like disconnecting right before connecting), and you shouldn't have problems.

Do this:
Add an INet control.
Call .OpenURL or .Execute on some page.
Call .Cancel and/or .StopExecution (I think).
Call .OpenURL or .Execute on some page, again.
Hit the "OK" button when the control tells you it's errored and watch you're program close.

[quote author=rabbit link=topic=13598.msg139131#msg139131 date=1135437050]
Do this:
Add an INet control.
Call .OpenURL or .Execute on some page.
Call .Cancel and/or .StopExecution (I think).
Call .OpenURL or .Execute on some page, again.
Hit the "OK" button when the control tells you it's errored and watch you're program close.
[/quote]
That won't cause an error because each line doesn't get executed until the one above have finished.

By adding that code into a command _Click() event or something. Then clicking that object twice in a row will cause the error even if the last line is to .Cancel it's last request.

I see no documentation saying that the Cancel method is guaranteed to finish immediately. There are several states you can get:

icDisconnecting 9 The control is disconnecting from the host computer.

icDisconnected 10 The control successfully disconnected from the host computer.

Try waiting for the control to finish cancelling the request it was working on before you give it a new request to execute.

[quote author=Adron link=topic=13598.msg139196#msg139196 date=1135490274]
I see no documentation saying that the Cancel method is guaranteed to finish immediately. There are several states you can get:

icDisconnecting 9 The control is disconnecting from the host computer.

icDisconnected 10 The control successfully disconnected from the host computer.

Try waiting for the control to finish cancelling the request it was working on before you give it a new request to execute.
[/quote]
Thus the reason why it is such a crap control. It should have these simply preventative measures built into it to stop crashing upon error, rather than getting the coder to check if it's connected or not continuously.

Shouldn't be expecting Microsoft to do everything for you...

Wow went wayy off-topic here.



Thank-you for all your help. I will look into it. When i have time, having good time since its xmas at the moment.

[quote author=FrOzeN link=topic=13598.msg139198#msg139198 date=1135494717]
Thus the reason why it is such a crap control. It should have these simply preventative measures built into it to stop crashing upon error, rather than getting the coder to check if it's connected or not continuously.
[/quote]

You are completely missing the point here. The control is *not* crashing upon error. The control is returning an error code to the application. Visual Basic has the built-in feature of crashing if the programmer fails to properly check for returned error codes. Blame Visual Basic if anything. Calling that control from C++ would not make it crash on an error.

[quote author=FrOzeN link=topic=13598.msg139198#msg139198 date=1135494717]
[quote author=Adron link=topic=13598.msg139196#msg139196 date=1135490274]
I see no documentation saying that the Cancel method is guaranteed to finish immediately. There are several states you can get:

icDisconnecting 9 The control is disconnecting from the host computer.

icDisconnected 10 The control successfully disconnected from the host computer.

Try waiting for the control to finish cancelling the request it was working on before you give it a new request to execute.
[/quote]
Thus the reason why it is such a crap control. It should have these simply preventative measures built into it to stop crashing upon error, rather than getting the coder to check if it's connected or not continuously.
[/quote]

It's not a crap control.  Sorry, this isn't the CleanSlateBot of Internet web page transfer.  Doing a simple "If-Then-Else" isn't much trouble and it's better practice anyways instead of being so damn lazy.  Perhaps you can write a better control for us to use which has the same ability as msinet.ocx (the Inet control).

[quote]Sorry, this isn't the CleanSlateBot of Internet web page transfer.[/quote]

Ahh, that made me chuckle.