I agree with this, but it is by design.

What happens is this:

mIRC triggers ON HOTLINK multiple times for different event types, very similar to the way ON DIALOG works. So you will get multiple triggers of ON HOTLINK, sometimes with the "event type" == mouse, sometimes lclick, sometimes rclick. The only difference is, unlike ON DIALOG, there is no "event type" match in the event definition to filter the triggers by type. It would be as if you had an ON DIALOG:*:*: definition that just catches all events.

Anyhow, in a "mouse" event type, /hotlink -m is not valid, and raises an error (this is the important part). So, to get around this, you need to ensure you're calling /hotlink -m from the right event. As far as I know, this is an explicit choice and by design.

IMO the real problem is that /hotlink raises an error and doesn't just quietly ignore invalid parameters. If it did so, we would need no if to handle this, and we could fill all our parameters into a single hotlink command, greatly simplifying the interface. Again, in my opinion, I don't see the rationale behind being so strict about switches; it certainly seems a little unprecedented, behaviour-wise, and it really makes things much more awkward and unfriendly to new users who don't understand the internal workings of the event.

Either that, or we should have an event type filter in the event definition like ON DIALOG so we can explicitly specify ON HOTLINK:*:rclick:hotlink -m ...

Of course, ignoring the invalid params would be useful either way, the 2nd suggestion is just a loosely related enhancement.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"