Forums Bug Reports $mouse.key issues

when upgrading a mirc 7.22 installation to 7.25, the new hotlink features do not work:

on *:HOTLINK:*.*:*: {
var %hle = $hotline(event)
var %hlm = $hotline(match)
var %hl = $hotline
echo -st Event: %hle Match: %hlm Line: %hl Mouse Key: $mouse.key
}

this echo's: "Event: Match: Line: whatever line I had my mouse on Mouse Key: 0"
in other words:
$hotlink(event) is always blank
$hotlink(match) is always blank
$mouse.key is 0 for a right click, vice the 16 it used to be
help file says use ($mouse.key & 16) to check for right mouse click

I am looking for hotlinks that have a period in them, that's why I use *.* for match

On a brand new, clean install of 7.25 in a new directory, everything works as it should.

So.... something doesn't work correctly when upgrading mirc.
Seems I would have to install a clean mirc 7.25, then move all scripts/popup/vars/data files over to the new mirc directory, remap any paths I may need in the various scripts, and data files.....

On a clean install of mirc 7.22, as a portable, then upgrading that to 7.25 as a portable, things work normally

Only when upgrading a "Non-Portable" existing 7.22 install to 7.25 does this occur.

You're saying you're matching line (it's rather "matching words" btw) that contain a dot '.', but %hl doesn't even contain a dot in your example...
More importantly, your example is using $hotline() which should be $hotlink(), which explain why those are $null.

$mouse.key is bugged indeed but I can get it to work when right-clicking from the status window (related to /echo -s..)

This is tested from an upgrade of a non-portable 7.22 to 7.25.
It seems that you didn't test this correctly, you should triple check the test you are making. It's almost certain that the problem isn't with upgrading from a non-portable 7.22 to 7.25 but is with you, except for $mouse.key, but in the meantime $hotlink(event) will tell you if you are right-clicking..

The code you posted is not valid in 7.22, so I'm not sure how this is relevant to an upgrade bug. This report is only about new behaviour in 7.25 and has nothing to do with 7.22. Portable/non-portable mode also has nothing to do with this bug. The topic of this post should be changed to be more relevant.

There are also errors in the code, as the correct identifier is $hotlink, as pointed out. The snippet works for me when it is corrected.

Finally, $mouse.key is not a bug here, it's simply not updated when the event is triggered. Note that in addition to the part you quoted, the help file also says: "The $mouse identifier can be used in the mouse/click events" (of MENU definitions); the behaviour should be considered undefined outside of MENU. Also note that the HOTLINK event has its own method for detecting a right click, so you should not be using $mouse.key. To detect a rightclick check for $hotlink(event) == rclick.

NICE. now how do I delete this entire thread.
hotline vs hotlink ... sheesh

Like I said in my post, $mouse.key is updated when the event trigger, just not always.
Right-clicking a word that trigger the event on a channel window while having the event set up to display $mouse.key in the status window show 0 for $mouse.key, everytime, for me.
Triggering the event with a right click from the status window correctly shows 16, everytime.

I updated the wording in my previous post-- my point is that while $mouse.key returns a value, the value should be considered undefined outside of its expected usage of MENUs. It might work in status windows, but you should not expect it to work-- it's specifically created for another purpose.

I believe you can edit your initial post and check a [x] delete box.

well with typo corrected, I don't need the $mouse.key & 16 feature, but Shift/Alt Right Click still returns $mouse.key values that I check for.

Thanks

Also, trying to delete post says "The post may no longer be deleted".

After trying it again, in fact it only shows 16 if I right click and then mouse-over, and $hotlink(event) is mouse, so this is fine.

Though, I still think $mouse.key should be updated here, whatever its original purpose, $mouse.key *is* actually updated in any situation but this one.
It makes sense to check for, let's say the shift key, inside an on hotlink event, seeing that it doesn't work look rather a bug than anything else to me
Note that the old on ^hotlink event updated the $mouse.key identifier correctly according to the help file

The $mouse.key value is being updated correctly here. In previous versions of mIRC, the hotlink event was triggered when the right mouse button was pressed, so scripters were testing for $mouse.key to detect a right click. In newer versions of mIRC, popup menu support was added to hotlinks and, in line with normal Windows behaviour, the hotlink event is now triggered when the right mouse button is released. So scripts that test for $mouse.key will correctly see that the right mouse button is not pressed.

For backwards compatibility, one possible solution would be to make $mouse.key report that the right mouse is pressed in this particular "rclick" hotlink context, even though it is not. If anyone thinks this could be a problem, let me know. Otherwise I will implement it for the next version.

I tested it again and you are right, $mouse.key works perfectly fine, and I don't think you should bother making a special case for backward compatibilities, but it certainly won't hurt.