Right, it appears that there are some issues/discrepancies with the implementation and/or documentation. Custom sockets support was added in 1997 and UDP support was added in 1999, which is probably what caused this.
(1) When sending UDP data, there is no guarantee that UDP will return an error, so a UDPWRITE event seemed unnecessary. That is why it was never documented. However, due to the custom sockets internal buffer support, on SOCKWRITE was being triggered when data was ready to be sent on a socket. The internal buffer support should really have been triggering on UDPWRITE to be consistent.
(2) An on UDPWRITE event does exist, however it is only triggered when there are socket errors. So on SOCKWRITE will not detect UDP errors. However, as UDP errors are rarely, if ever, reported by winsock, this may not make much difference.
(3) From an implementation point of view, the UDPWRITE/UDPREAD events should probably not have been added as UDP could have continued to use the SOCKWRITE/SOCKREAD events. The scripter would know which sockets were UDP or TCP based on the socket name.
As it stands, the most backward-compatible solution would be to change (2) so that on SOCKWRITE is triggered when an error occurs and to remove the UDPWRITE event as it is not documented any way. This change will be in the next version.
That said, this may not resolve the original issue reported in this post, so we will need to look at this again once a public beta is released.
