Forums Feature Suggestions on open ? behavior

I find the behavior of the on open command weird. It only triggers when someone queries me and not when I open a query window. The on close event triggers whether someone queried me or I opened the window myself. I feel the on open should trigger when I open a query with someone.

on *:open:?:*:echo -s Just opened $target query window
on *:close:?: echo -s closed $target query window

(Yes I did post this in another section. I just wanted opinions and no one argued that it should work this way, so here we are.)

Use this alias:

Damn I was wanting to post this in bug reports since the behavior is off in my opinion.

Thanks for the alias but it doesn't account for all the ways a query window can be opened. Making the on open work no matter how the window was opened is the best solution.

You did post this in 'Bug Reports', it was moved. It's certainly not an mIRC bug.



The alias takes account for all the ways you open a query window.

Use alias + on open event.


Might be an issue in terms of backwards compatibility.

There is no backwards compatibility issue with added behaviour.

Using an alias doesn't account for all the ways "you" open a window. Namely, a script can still use /!query to bypass the alias, secondly, there are many non-command ways to get a query window: selecting "query" from the Notify window is one of them-- that behaviour is not overridable, nor is it tied to /query.

For what it's worth, the behaviour has to do with a somewhat archaic convention mIRC used to use regarding event triggering. In the past, the convention was that no event would ever fire if there was a command equivalent to trigger it. Recently, however, ON CLOSE was changed, and therefore it's probably time that ON OPEN changes as well for consistency's sake.

No? Scripts use on open for query flood protection.

That's a good thing, if you want to bypass the alias.

Query popups?



Because of the '/remove <nick>' command on some networks? (Not sure about this)

And setting on open to trigger when you open a query isn't going to affect a query flood protection script. It's not like you're going to open enough queries yourself fast enough to trigger that kind of script.

I really doubt there's any backward compatibility issues with triggering on open when you open the query. If there are, it likely means a script is so badly written that it needs to be updated anyhow.

Also, your query popups isn't what argv0 was referring to. That still uses /query, so it *is* covered by the alias shown. argv0 was referring to things that the alias wouldn't cover.

Something like:

fself alias increments number, closes window, ignores, sends messeges....

If you open two querys that adds 2 to flood check, if you get 4+ querys from bots, that adds too.

What about 'PM / Query Blocker' scripts?
What about messeges sent when query opens, like away messeges?



n2=Query:/query $$1 (The qpopup is the notify menu too)



This is what argv0 was referring to.

Possible solution?

Crinul, you are stretching here. It's ON OPEN not ON QUERY. A query is a private msg, or a /msg. /query <nick> <msg> opens a window. It should call the ON OPEN event.

Who is going to use ON OPEN for flood detection? Once the query window is open ON OPEN is not called again. (Actually I have not tested this... omigod please tell me it doesn't call ON OPEN whenever you get a private query!)

The help file is also incorrect.

Format: on <level>:OPEN|CLOSE:<?|@|=|!|*>:<matchtext>:<commands>

OPEN and CLOSE are not identical... they should be but they are not.

Query flood, not (TEXT,NOTICE,ACTION,CTCP,WHATEVER).

A "query" triggers the ON TEXT event. In fact... try using //msg $chan $+ , $+ $me Hello World.

The number of query windows, that's what query flood is.
Not the text sent when the query window is open.

When you right-click a name in the notify window, it will display the query popups. In other words, right-clicking to query someone in the Notify window does in fact use /query.

In fact, I've tried to find a way to open a query window that doesn't use /query and as far as I can tell, none exists. Do you have any specific examples where /query is not triggered?

this is a good point that doesn't seem to have been addressed. sure, if on OPEN's functionality were extended in the manner described, scripters could still check $rawmsg or the value of certain remote identifiers to determine whether the window was opened on receipt of a PRIVMSG, but the change would still affect all scripts that presently do not.

argv mentioned on CLOSE's recent change, but it still doesn't trigger when you use /window -c or /close, nor should it. MeStinkBAD, by that very reasoning on SOCKCLOSE should trigger even when /sockclose is used, which it currently doesn't.

on OPEN (for query windows) without an incoming message should only trigger if /query was not used to open it, if indeed such an example exists.

Actually, I'd think it should. That functionality has actually been suggested a few times before. As I mentioned, mIRC's policy *used to be* that /commands don't trigger events-- but frankly, that policy isn't really upheld like it was, nor is there any reason to.

Why shouldn't /close trigger ON CLOSE? I don't really see a reason. A window closed. There should be a centralized way to catch this occurrence. The change to make ON CLOSE work for channels means that clicking the x button triggers the event. Why is clicking with the mouse any different from typing a /command?

I don't really buy overriding builtin /commands to be a viable alternative. Sure, you *can* override /query, or /close, but there are more ways to /close a window (/window -c)-- you a) can't override them all easily, and b) the second you have 2 scripts running that both modify the alias, you're screwed. mIRC's event-based design is what makes scripts modular and robust. The answer should not be "override /query to trigger ON OPEN". That's a hideous hack.



This is a pretty bad example, because /sockclose is actually dreadfully inconsistent w.r.t. the other /sock* commands, so you basically just opened a can of counter-argument-worms. Actually, by your reasoning, /sockopen should not trigger ON SOCKOPEN. Similarly, /sockwrite should not trigger ON SOCKWRITE. Frankly, I'll bet neither of us think that's a good idea. The consistent thing to do would be to make /sockclose trigger ON SOCKCLOSE, like the other commands. But this is a conversation about ON OPEN, not sockets, so that's another discussion.



I don't see the issue. "query blocker" scripts tend to be in the form:



That generally means you don't want to open a query with that nickname anyway... Sure, currently you can override this with /query, but IMO the "backwards incompatibility" here is minor. Oh no, you can no longer open a query with a nick your script is specifically designed not to open queries with.

Also note that mIRC can easily mitigate this by ignoring /halt in the ^ version of ON OPEN if triggered by you-- that is to say, it won't halt if *you* open the window. That solves most related scripts (and gives you the current behaviour of overridability), while still being able to at least *trigger* the event.

The alternate form of these blockers is:



This doesn't even pose an incompatibility, since $1- (and matchtext) should be empty if you trigger the opening of a window anyway.

I can't think of another form besides maybe flood control, but again, that shouldn't cause significant incompatibilities.

to remain consistent with the standard that it's adhered to ever since its introduction. i'm not saying there shouldn't be a comfortable way to intercept ALL window closures, i just think it ill-advised to make such changes willy nilly. it's a shame that on OPEN/CLOSE didn't exhibit this fuller functionality to begin with; scripters have now become used to and perhaps, at times, rely on present behaviour.



it isn't! in cases like these, scripters should endeavour to include the necessary handling with the portions of their scripts that use the /query, /close etc. commands. even though it can be out of their control, this is the sensible approach to the problem, and the one that should be mentioned first and foremost.



no no, the key difference with on SOCKCLOSE is that it is triggered in response to external stimuli whereas those other events trigger only as a direct result of their respective /sock* commands. there are only a handful of events that are appropriate to the discussion (ones that can conceivably trigger in direct response to a command or from an external message); on SOCKCLOSE was the first that came to mind :P



sometimes, sometimes not. what you have there is just about the same as adding foo!*@* to your ignore list for private messages. a more common example is something similar to:



to suddenly change on OPEN in the proposed way would be undesirable for the user of such a script, don't you agree?

a more pragmatic approach would be to introduce a new event prefix to have on OPEN/CLOSE trigger in response to commands, as well as what they currently do:



as such, compatibility with older versions is fully preserved

I agree with you.
Seconded.

Show me where this "standard" is written. Implementation is not a standard. Implementation is an implementation *of* a standard. The implementation can be wrong or simply outdated. And in fact, with the change of ON CLOSE for channels, we've seen that this "standard" has in fact been changing over the last few versions.



But ON SOCKOPEN is not. Neither is ON SOCKWRITE. They don't trigger randomly, they trigger in response to typing /sockopen or /sockwrite respectively. Sure, there might be a delay, sometimes significant, but it's not "external stimuli". The trigger is specifically coming from your end, namely the /sockwrite or /sockopen-- it can never happen in any other manner. There is an inconsistency here. Personally, I'd rather see things in the form of ON SOCKWRITE/ON SOCKOPEN, because they are much more useful.



Sorry, no, I don't acknowledge this as more common. You're using workarounds to make things work when they should not-- ie. a /timer to make $input work even though mIRC does not allow modal dialogs in events (for a very good reason). Let these scripts break. We're not going to argue that maintaining backwards compatibility is more important than allowing for unintentional functionality.



Extra prefixes are not necessary. I already proposed a reasonable implementation that preserves the functioning of "common" scripts (including the one above, although I don't consider it common). To repeat, /halt in a ^ event will not /halt if triggered by you. mIRC can implement an internal switch without affecting the usage. Whether you can /halt your own /queries isn't absolutely necessary. The real heart of this issue is simply being able to get a callback when you /query-- that's really all that's being asked for. In that sense, I think losing /halt on self-triggered OPEN events is a reasonable compromise. Probably not too hard to implement, either.

Saying ON SOCKOPEN or ON SOCKWRITE are triggered in response to /sockopen or /sockwrite is equivalent to saying that ON TEXT is triggered by //msg $me hello. In both cases events occur outside the scope of mIRC with unpredictable delay. Just because /sockopen or /sockwrite started a chain of events doesn't mean that no external stimuli were involved at a later point.

No, there is an important difference here: mIRC will *always* trigger ON SOCKOPEN. An "unpredictable delay" does not mean it's not triggered by you. It may not always come within X ms, but it is guaranteed to be triggered. You can get an unpredictable delay from many events that you trigger, /dns being the first example that comes to mind. And yet, /dns is guaranteed to trigger ON DNS in the same way ON SOCKOPEN is guaranteed to be triggered by /sockopen, regardless of the delay.

This is very much unlike ON TEXT for a few reasons. First, ON TEXT is specifically in response to the server sending you a message, which means there is no guarantee that message will ever be sent. No, //msg $me hello does not guarantee an ON TEXT event will trigger. You must be connected, the server must allow that command, etc. Only at this point is another external "entity" making a decision about what you will receive.

ON SOCKOPEN does not go through any external entity to get the data necessary to trigger the event. It is an inherent part of the control flow of /sockopen. You can think of /sockopen as being implemented by the following pseudo-code:



I used a blocking call to connect(), which mIRC may or may not be doing, but one thing is being done by both implementations: the event is triggered after connect() finishes, regardless of whether the connection was successful. In this sense, and certainly if you look at the pseudo-code above, the ON SOCKOPEN event is a direct result of the /sockopen command. Sure, connect() blocks for an indefinite amount of time, but that doesn't make the event any less direct a result of the command.