dlf retries a dcc get which was explicitly cancelled by the user

[Sophist-UK]

I have asked in mIRC forums if it is possible to distinguish between a DCC GET failure caused by communications errors or one explicitly cancelled by the user.

[Sophist-UK]

No answer in mIRC forums. Options for explicit cancel are:

A. User requested to Accept/Ignore/Cancel - GETFAIL event is NOT called if user selects Ignore or Cancel so DLF does not attempt a retry - which is as we would want it.

B. User clicks Cancel in DCC Get window. In which case, this is the active window when GETFAIL is triggered and we can test for this and avoid a retry. However if window is active it could be:

B1. User clicked cancel; or
B2. Connection failed before bytes were sent; or
B3. Connection failed after bytes were sent.

As far as I can tell, these are impossible to test for definitively using e.g. .idle, or .rcvd, so we can only assume that if the window is active, chances are that user clicked Cancel, but it could have been a comms failure.

C. User right clicks on Treebar or Toolbar and selects close in which case window is not active and there is no way to distinguish between this and comms failure.

We could try to use $get(-1).idle = 0 or 1 - the number of seconds since data was sent - but on a slow connection this could be > 1 when user cancels, or if sender closes the TCP connection or user loses connectivity that the PC can recognise (like disconnect of wifi) this could be 0 and a comms failure.

Planning to leave as-is - any Get failure results in a retry - but open to alternative suggestions. But idle = 0 or 1 seems best bet so far.