mIRC Home    About    Download    Register    News    Help

Topic Options
#264177 - 06/11/18 07:40 PM //clipboard $null sets $cb(0) to 1
maroon Offline
Hoopy frood

Registered: 12/01/04
Posts: 1144
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.

#264308 - 18/11/18 09:58 PM Re: //clipboard $null sets $cb(0) to 1 [Re: maroon]
Khaled Offline

Planetary brain

Registered: 04/12/02
Posts: 4437
Loc: London, UK
Thanks for your bug report. The issues you mention have been fixed for the next version. $cb() will need heavy testing in the next beta.

Regarding the intermittent $cb() results: I was able to reproduce this. It is due to Windows or other applications locking the clipboard, a shared resource, using OpenClipBoard(), and preventing access. This prevents mIRC from using GetClipboardData() or SetClipboardData(). There are several discussions on stackoverflow about this and the only solution seems to be to make the application try to open the clipboard several times. I implemented this for both /clipboard and $cb() so that mIRC attempts to lock the clipboard up to ten times. Unfortunately this did not work reliably and only calling Sleep(10) in between each attempt, to give other applications time to release the clipboard, resolved the issue. This means that calling either /clipboard or $cb() can now take 100ms in total. Note that there is still the possibility that they could fail as the process depends entirely on how long another application locks the clipboard.