The 1st command shows that /clipboard sets $cb(0) to 1 even though the clipboard appears empty to all mirc functions. $bvar(&v) shows that the binvar created by $cb(-1,,&v) does exist, but has null length.
//clipboard $null | echo 4 -a cb(0)= $cb(0) | noop $cb(-1,,&v) | echo 3 -a binvar $bvar(&v) len= $bvar(&v,0)
However if I let MS Excel fill the clipboard with Ctrl+C then let Excel clear it with F2, the following command which excludes the /clipboard command shows that $cb(0) is now $null and the &v binvar doesn't get created as null length. I get the same behavior by using the [printscreen] button to empty the text clipboard that wasn't already 'cleared' by /clipboard.
//echo 4 -a cb(0)= $cb(0) | noop $cb(-1,,&v) | echo 3 -a binvar len= $bvar(&v,0)
This behavior was happening both in 7.52 nobeta and the newest beta. But in v6.35 it shows the red cb(0) being $null.
It seems reasonable that an empty clipboard should be 0 instead of $null, but if that's the backwards compat behavior, fine. But returning 1 for an empty clipboard if created by mirc but not by Excel is a bug.
As for whether $cb(-1,,&v) creates a null-length binvar or not, depending on whether the clipboard was emptied of text by [printscreen] or by /clipboard, i'm not sure if that's new enough to not be governed by backwards compatibility. I do know there are examples where it's appropriate for a null-length binvar to get created from null input. But in spite of that, I'm thinking that /clipboard should continue create a null-length binvar if it's been doing that since the feature was added.
//noop $regsubex(temp,$null,,,&var) | echo -a $bvar(&var) $bvar(&var,0)
//hfree -w table | hmake table | hadd table item | noop $hget(table,item,&var) | echo -a $bvar(&var) $bvar(&var,0)
Not sure if this next is related to the above, but while Wims also sees the above behavior, he's not seeing the behavior below.
//clipboard line 1 $crlf line2 | noop $cb(-1,,&v) | echo -a cb(0)= $cb(0)
When I repeat this command multiple times, sometimes $cb(0) is 2 and sometimes it's $null. If I repeat without the middle noop command, it's always showing 2. Happens for me both in no-beta and new-beta. Not sure if the noop command needs to lock the clipboard to copy it, and isn't always being released fast enough.