Forums Feature Suggestions on open ? behavior

You can make a 'PM / Query Blocker' script without using $input.
You can check (hash table, text file, access level, variables) and depending on result: close query, ignore nick, send message.

Not common?

Query blockers are common (I provided 2 simple examples myself), don't misquote me. Query blockers in the form provided by jaytea are not. Most are setup to specifically block certain names or message patterns beforehand. As I mentioned, these specific types of scripts would not be affected by the change.

The only ones that would be are those that arbitrarily block nicknames based on modal user input (an invalid case, as I mentioned), or flood control scripts. For flood control, there are alternatives out there (like mIRC's builtin flood control), and worst case scenario is that you accidentally trip your flood control with /query, so it's not a huge incompatibility.

Also, given how *common* query blockers are, how easy they are to script, and how many alternatives are available (server-side ignore, /ignore, mIRC flood control, etc.), breaking a few of these scripts becomes less of a big deal. At least in this case, users have alternatives, and the simplicity of these scripts (they all seem to be < 100 lines of code) means it is trivial to fix them.

Progress should not be stunted simply for backwards compatibility's sake. There's more to the argument than "scripts will break"-- part of the question is: "how bad will it be if they break?". In this case, not so bad.

I thought you meant scripts like that, query blocker scripts.



This are compatibility issues, not everyone knows how to fix them.

'server-side ignore', what if the network doesn't support it?
'mIRC flood control', you can't customize it (change my nickname, etc.)
'/ignore', before flood occurs?

My point was that there are enough alternatives that people don't need to fix them on their own. Plenty of such scripts will *not* break, or be promptly updated upon a new release. Your link shows over 20 separate scripts, that's a lot of options for the layman.



Again, these are *options*. Not all options will automatically work for everybody, but in most cases at least one option will be available. In the case where none of these options work, we can talk about the fact that there are tons of scripts out there to pickup the slack. And I'll bet there would be plenty that would be updated soon after mIRC released a new version, if the behaviour changed.

I just think the idea that a broken script will never be updated is a little faulty. It's certainly a concern for monolithic scripts that no longer get maintained (ircN, PnP, etc.), but small snippets like query blocking should not pose a problem. There are enough alternatives and enough interest to update such scripts.

apparently you misunderstood me, or we're thinking about this in different ways. on SOCKOPEN and on SOCKWRITE only follow their respective /sock* commands (i said this originally). you said this:



that's wrong. on SOCKCLOSE doesn't follow /sockclose because there is an external stimulus involved. this external stimulus does not come in to play with on SOCKWRITE or on SOCKOPEN, that's why it's not sensible to compare them to on SOCKCLOSE.



you missed the point i'm afraid. i realize that specific method is uncommon (it's the only example i had, commented out, in my scripts), that's why i qualified it with 'similar to'. what we would typically see is more like:



not great, but typical. i'm not saying the fixes would be complicated, but why do you want to introduce a problem? we've already witnessed the effects on the public of abrupt changes to the client, namely: discontinuation of code page support.

the way i see it, it's as simple as: if you change on OPEN then some people will be impacted negatively, if you add an event prefix then they will not. you said it yourself:



what you're proposing is a change, what i'm proposing is added behaviour.

jaytea, you sure are digging yourself a deeper and deeper hole...

frankly, i don't know what you're talking about

I'm glad to see some one agree with me. Also please don't get too off topic.

Lastly if mirc doesn't ever break backwards compatibility it can't move forward (not that i feel this change would do anything bad). That's why scripts should/do include what versions they work with. If it doesn't work with a new version tough luck, fix it or bug the creator to fix it.

I'm responding to everyone, not just argvo.

First of all, I was surprised that certain windows do not trigger the close or open events, but finding a work around was pretty easy. I wouldn't mind support for this but it is unnecessary.

As I said in the original post, if you want to know when a query window has been opened, either you monitor when YOU OPEN THE WINDOW, or you recognize the very first query from someone. At this point you can double check $query($nick).

I don't see how lack of open or close event for a query window would make it so you cannot write a flood protection. Depending on your server there are a few ways to monitor queries.
Ex:
on *:text:*:?:{
raw whisper:*:{

I wrote a few query block scripts. They basically monitored incoming queries and if the person was blocked, either it didn't allow the query window to open in the first place, or it closed the window when needed.

And more importantly, for a backwards incompatible change of this kind, (a) the bug is minor and (b) there are many alternatives already.

How do you do that without overriding aliases? I had already pointed out that overriding /query is extremely poor form, and a very brittle solution at that, since any secondary script that also overrides the alias would effectively wipe your code. A solution that only works "if you don't load any other scripts" isn't much of a working solution, hence the motivation for the suggestion.



Nobody said that you cannot write flood protection scripts if this change is made. What was said was that a small amount of scripts may break due to this change, because of the fact that ON OPEN is generally /halt'ed in these situations.

[Not specifically directed to you, DJ_Sol]:

Again, I should point out that a (far more) backwards compatible way to implement this feature addition would be to trigger ON OPEN for the user opening a query window locally, but *not* the ON ^:OPEN variant. The OP is not looking for a way to halt opened windows, just a reliable and centralized way to detect them.

There's absolutely no reason to break backwards compatibility when there are several perfectly good workarounds for this situation already.

One such example that comes to mind is simply changing the alias that is called when you double click on a name in the nicklist through Alt+O > Options > Mouse. Change it to something like my_query_alias_that_nobody_else_will_use and you can be sure it won't be overwritten

If the on open even was to be modified then perhaps there can be something similar to $menucontext so that the scripter knows how the window opened.

That way, all existing query blocker scripts that make use of on OPEN could keep their existing functionality by simply wrapping the code block in something like:

Well I connect to my server using a socket so I can use the local socket if I want to. I would have to see the purpose and point of a specific script to comment on how I would know if I opened a query window or not. Bottom line is that you use the /query command to open a query window. You could make an alias that does some checks then opens a query window with the /query command and put that alias in the "command to be performed when you double click the nicklist".

I monitor incoming queries and my input:?: event. I guess you could set a timer to check for query windows but that sounds pretty silly.

This is the same problem as overwriting the alias, the problem is just displaced. The option itself can be overwritten, so we're still talking about a centralized point of failure. More importantly, it means only one script can access this information at a time, which is still not a sufficient solution. If I change the alias to "my_query_alias_that_nobody_else_will_use", I break "my_other_scripts_query_alias". This is definitely a workaround, but not even close to a "perfect" one. The whole point of having events is to allow scripters parallel and independent access to state operations. Just like the joining of a channel, one such state operation is the opening of a query window.

Also note that the default popups menu uses /query, so that would need to be changed too. Again, you run into the problem of multiple scripts potentially modifying one centralized setting.

I'm not sure why everyone is so hung up on backwards compatibility, as mentioned, there are a dozen ways in which ON OPEN can trigger WITHOUT breaking backwards compatibility. Let's stop talking about a problem that does not exist.

I just think backwards compatibility should be maintained when there are acceptable (admittedly, not perfect) workarounds available.

Perhaps this could be another event that supports the undocumented "me:" prefix so that you can catch the event triggering yourself.

Although that does well for making everyone happy, it also means there's a difference in how the non-use of the me prefix works depending on the event. For example, using me for on OP will trigger only for you. That would still be true for on OPEN with this example. However, with on OP, not using it means it triggers for everyone including you (based on the level prefix, of course). Not using it for on OPEN, however will trigger for everyone except you. Although the difference in minor and most scripters won't care one way or another, it does add to potential confusion for any new scripters because of the difference in how it works. Of course, since it's undocumented and isn't changing how it currently works, maybe it doesn't matter. I'd just expect any event that takes the me prefix to have the same 2 possibilities - me = just me, no me = everyone including me.

I don't really care either way. I do any flood protection on the TEXT event anyhow rather than the OPEN event and it works very well. Just thinking that having that difference between how it works between events might not be a good thing. Still, anything done or not done will likely not be a perfect solution for everyone, and this is probably the best solution I've seen in this thread even though I personally don't think worrying about backwards compatibility is a good excuse for not making the change in this event. It really won't affect all that many scripts and the improvement can help all of those AND more scripts, so it's a win-win for everyone once the scripts are updated and updating them is very easy.

Let me be clear, my proposal is this:

ON ^*:OPEN: should not trigger for self-opened query windows. Only ON *:OPEN: should trigger.

Since these /halting flood/spam control scripts make use of ON ^*:OPEN:, this will maintain backwards compatibility for 99.9% of existing scripts-- certainly all the ones I've seen, and all of the ones that were listed here.

As a backup, I wouldn't mind the ME: prefix, but I think simply not triggering the haltdef'd open event effectively avoids the problem.

That would work too

The open event isn't triggered is the user uses a single message window. It's only fired if it's disabled and a query window doesn't already exist for the specific user. The on text event is always fired.

The problem I have is a window opening has nothing to do with receiving a private message. mIRC just happens to open a query window if the appropriate options are set. Ironically there is no option not to open a window and treat the message like it does a notice.

The open event will also fire before the on text (or ctcp action) event strangely.