Posting in a shoutbox on piczo?

[rabbit]

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

[Adron]

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

It is meant to be handled...

[rabbit]

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

[Adron]

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

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.

[rabbit]

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.

[Adron]

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.

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.

[Warrior]

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.

[topaz]

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.

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.

[rabbit]

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.

[FrOzeN]

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.

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.

[Adron]

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.

[FrOzeN]

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.

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.

[topaz]

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

[QwertyMonster]

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.

[Adron]

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.

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.