mIRC Home    About    Download    Register    News    Help

Print Thread
Page 1 of 2 1 2
#227472 10/11/10 11:54 PM
Joined: Nov 2009
Posts: 295
P
pball Offline OP
Fjord artisan
OP Offline
Fjord artisan
P
Joined: Nov 2009
Posts: 295
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.)


http://scripting.pball.win
My personal site with some scripts I've released.
Joined: Feb 2006
Posts: 181
C
Vogon poet
Offline
Vogon poet
C
Joined: Feb 2006
Posts: 181
Originally Posted By: pball
I feel the on open should trigger when I open a query with someone.


Use this alias:

Code:
query {
  var %c = !query
  if ($1 == -n) {
    %c = !query -n
    tokenize 32 $2-
  }
  if ($1 == $null) halt
  if (!$query($1)) {
    %c $1
    echo $1 * You just opened this query window
    %c $1-
  }
  else %c $1-
}

Last edited by Crinul; 11/11/10 12:38 PM.
Joined: Nov 2009
Posts: 295
P
pball Offline OP
Fjord artisan
OP Offline
Fjord artisan
P
Joined: Nov 2009
Posts: 295
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.


http://scripting.pball.win
My personal site with some scripts I've released.
Joined: Feb 2006
Posts: 181
C
Vogon poet
Offline
Vogon poet
C
Joined: Feb 2006
Posts: 181
Originally Posted By: pball
Damn I was wanting to post this in bug reports since the behavior is off in my opinion.


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

Originally Posted By: pball
Thanks for the alias but it doesn't account for all the ways a query window can be opened.


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

Use alias + on open event.

Originally Posted By: pball
Making the on open work no matter how the window was opened is the best solution.

Might be an issue in terms of backwards compatibility.

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
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.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Feb 2006
Posts: 181
C
Vogon poet
Offline
Vogon poet
C
Joined: Feb 2006
Posts: 181
Originally Posted By: argv0
There is no backwards compatibility issue with added behaviour.


No? Scripts use on open for query flood protection.
Originally Posted By: argv0
Namely, a script can still use /!query to bypass the alias

That's a good thing, if you want to bypass the alias.
Originally Posted By: argv0
selecting "query" from the Notify window

Query popups?
Code:
menu query {
  Custom Query:query $$1
}

Originally Posted By: argv0
Recently, however, ON CLOSE was changed, and therefore it's probably time that ON OPEN changes as well for consistency's sake.

Originally Posted By: whatsnew.txt
20.Extended on CLOSE event to work with channels.

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

Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
Originally Posted By: Crinul
Originally Posted By: argv0
There is no backwards compatibility issue with added behaviour.


No? Scripts use on open for query flood protection.


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.


Invision Support
#Invision on irc.irchighway.net
Joined: Feb 2006
Posts: 181
C
Vogon poet
Offline
Vogon poet
C
Joined: Feb 2006
Posts: 181
Originally Posted By: Riamus2
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.


Something like:
Code:
on ^*:OPEN:?:*: fself $nick $me $wildsite $address

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?

Code:
[qpopup]
n0=Info:/uwho $$1
n1=Whois:/whois $$1
n2=Query:/query $$1
n3=-
n4=Ignore:/ignore $$1 1 | /closemsg $$1
n5=-
n6=CTCP
n7=.Ping:/ctcp $$1 ping
n8=.Time:/ctcp $$1 time
n9=.Version:/ctcp $$1 version
n10=DCC
n11=.Send:/dcc send $$1
n12=.Chat:/dcc chat $$1


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

Originally Posted By: argv0
selecting "query" from the Notify window


This is what argv0 was referring to.

Possible solution?
Code:
on me:*:OPEN:?:*: echo -s You just opened this query window

Joined: Apr 2003
Posts: 342
M
Fjord artisan
Offline
Fjord artisan
M
Joined: Apr 2003
Posts: 342
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.



Beware of MeStinkBAD! He knows more than he actually does!
Joined: Feb 2006
Posts: 181
C
Vogon poet
Offline
Vogon poet
C
Joined: Feb 2006
Posts: 181
Query flood, not (TEXT,NOTICE,ACTION,CTCP,WHATEVER).

Joined: Apr 2003
Posts: 342
M
Fjord artisan
Offline
Fjord artisan
M
Joined: Apr 2003
Posts: 342
Originally Posted By: Crinul
Query flood, not (TEXT,NOTICE,ACTION,CTCP,WHATEVER).


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

Last edited by MeStinkBAD; 12/11/10 07:20 PM.

Beware of MeStinkBAD! He knows more than he actually does!
Joined: Feb 2006
Posts: 181
C
Vogon poet
Offline
Vogon poet
C
Joined: Feb 2006
Posts: 181
Originally Posted By: MeStinkBAD

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.


Joined: Dec 2002
Posts: 344
D
Pan-dimensional mouse
Offline
Pan-dimensional mouse
D
Joined: Dec 2002
Posts: 344
Originally Posted By: Riamus2
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.


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?

Joined: Feb 2006
Posts: 546
J
Fjord artisan
Offline
Fjord artisan
J
Joined: Feb 2006
Posts: 546
Originally Posted By: Crinul

What about 'PM / Query Blocker' scripts?


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.


"The only excuse for making a useless script is that one admires it intensely" - Oscar Wilde
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Originally Posted By: jaytea
but it still doesn't trigger when you use /window -c or /close, nor should it.


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.

Originally Posted By: jaytea
by that very reasoning on SOCKCLOSE should trigger even when /sockclose is used


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.

Originally Posted By: Crinul
What about 'PM / Query Blocker' scripts?


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

Code:
ON ^*:OPEN:?:*:if ($nick == foo) halt


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:

Code:
ON ^*:OPEN:?:*some banned phrase*:halt


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.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Feb 2006
Posts: 546
J
Fjord artisan
Offline
Fjord artisan
J
Joined: Feb 2006
Posts: 546
Originally Posted By: argv0
Why shouldn't /close trigger ON CLOSE? I don't really see a reason.


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.

Originally Posted By: argv0
I don't really buy overriding builtin /commands to be a viable alternative.


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.

Originally Posted By: argv0
Actually, by your reasoning, /sockopen should not trigger ON SOCKOPEN.


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

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

Code:
ON ^*:OPEN:?:*:if ($nick == foo) halt



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:

Code:
on ^*:open:?:*:%q = $nick : $1- | .timerq 1 0 $eval(%q = $input(Accept pm? %q, y), 0) | .timerq -e | if (!%q) halt


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:

Code:
on ~*:OPEN:?:*:{ ; triggers for all query window openings }


as such, compatibility with older versions is fully preserved


"The only excuse for making a useless script is that one admires it intensely" - Oscar Wilde
Joined: Feb 2006
Posts: 181
C
Vogon poet
Offline
Vogon poet
C
Joined: Feb 2006
Posts: 181
Originally Posted By: jaytea

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:

Code:
on ~*:OPEN:?:*:{ ; triggers for all query window openings }


as such, compatibility with older versions is fully preserved


I agree with you.
Seconded.

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Originally Posted By: jaytea
to remain consistent with the standard that it's adhered to ever since its introduction.


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.

Originally Posted By: jaytea
the key difference with on SOCKCLOSE is that it is triggered in response to external stimuli


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.

Originally Posted By: jaytea
a more common example is something similar to:

Code:
on ^*:open:?:*:%q = $nick : $1- | .timerq 1 0 $eval(%q = $input(Accept pm? %q, y), 0) | .timerq -e | if (!%q) halt



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.

Originally Posted By: jaytea
a more pragmatic approach would be to introduce a new event prefix to have on OPEN/CLOSE trigger in response to commands


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.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Dec 2002
Posts: 344
D
Pan-dimensional mouse
Offline
Pan-dimensional mouse
D
Joined: Dec 2002
Posts: 344
Originally Posted By: argv0
Originally Posted By: jaytea
the key difference with on SOCKCLOSE is that it is triggered in response to external stimuli


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.


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.

drum #227548 14/11/10 02:13 AM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Originally Posted By: drum
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:

Code:
/sockopen {
  MIRC_SOCKET_STRUCT *socket = create_socket();
  /* read in arguments */
  socket->fd = connect(socket->fd, socket->hostname, sizeof(hostname));
  socket->err = WSAGetLastError();
  trigger_event(EVENT_SOCKOPEN, socket); 
}


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.



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

Link Copied to Clipboard