/partall should part almost immediately.

When connected to a BNC and dropped from the server, the PART and PARTALL commands become useless because mIRC waits for a PART message from the server. Normally, mIRC does not wait for PART messages when it is disconnected, however, because of the BNC connection it's not sure of its connection state.

I propose that PART and PARTALL only wait for PART messages from the server for 2 or 3 seconds... after then, it closes the channel windows regardless.

This will save the user frustration in times of lag and connection issues, especially when it is important that they do not re-join said channel when they reconnect.

- Raccoon

And then when messages start coming from the server, lagged, about the channel? What then?

The current way is fine. Just force the window to close if you really want it out of the way.

Quote:

And then when messages start coming from the server, lagged, about the channel? What then?

Then mirc should ignore them.

I agree that this would be a nice feature.. no need to keep a window open for a channel that you're trying to close, especially if they will rejoin on connect. Also, I am ignorant of any /command that closes channel windows other than /part or /partall (after the server responds) unless you want to mess with com objects...

Code:

 /join #0,0

Hrung is correct, there are no commands to force a window to close. It is this lack of force-closeness which inspired my post on the matter. (and no, JOIN 0 is a server command, and will not work when disconnected)

If Khaled can make /window -c work on #channels too, and this would make people happy, then great!

I suggested a delay to try and prevent out-of-order (race conditions) from occuring, such as deoping someone and parting right away... mIRC would receive the On DEOP event for a closed channel. I'm not sure many scripts would be able to cope with that.

You do realise that you can just type /join 0, there is no need for the #0.

When you close a channel window (even when data is still being sent) it's sent to the status window anyway. I guess mIRC will either ignore the data (as it should for this as well) or just do it the way it's currently done (to the status window).