mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Feb 2003
Posts: 2,812
Raccoon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
On ^OPEN query doesn't work for triggering if the client uses Single Message Windows (aka Dedicated Query /dqwindow), unless the message is going to open its own query (nickname is in /notify list).

The behavior I expected was either one of 1) Trigger when the DQ window itself is about to be created, or 2) Trigger whenever nickname messages you for the first time so they can receive a welcoming introduction, their identity can be scrutinized, tallied or muted from ever appearing in the DQ window. IE: as if handling regular opening query windows from them.

Hard to say what the intended behavior should be. DQ window handling is rather tricky overall, especially when trying to /echo to the correct query window where their text appears in.

Code:
  var %cmd
  if ($query($nick)) { var %cmd = echo -tic info $nick }
  elseif ($window(Message Window)) { var %cmd = echo -dtic info }
  else { return } ; message halted or shown in active window?
  %cmd * $nick is also in $comchanS($nick).




Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Jul 2006
Posts: 4,145
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
Well on open triggers when a window is going to be created. It doesn't look like a bug to me, I suppose 1) is current behavior, where 2) is something you would like to handle, I think you should just work the logic out from on open and on text


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Feb 2003
Posts: 2,812
Raccoon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
Wims: Neither 1) nor 2) are the current behavior. If you have SMW enabled, On Open Query will only trigger for users in your /notify list. There is no event hook for when the $window(Message Window) is Opened. There's no straightforward way to determine if a nickname messages you for the first time to the Single Message Window.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Jul 2006
Posts: 4,145
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
Alright then the single window message not triggering on open is what I would report as the bug.

Last edited by Wims; 24/02/17 02:09 PM.

#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Indeed, the on OPEN event has only ever triggered for specific window types.

on OPEN triggers for users in your notify list if you have the "use query for notify nicks" enabled in IRC/Options, which means that a query window is opened - so naturally, on OPEN is triggered.

The reason this was never extended to the message window is that 1) it was not clear how it would affect scipts that had catered for existing behaviour over the 10-20 years it had been in place, and 2) it was not clear how best to implement it.

Possible solutions might be:

1) Trigger on OPEN when the message window is about to be opened but set an identifier $smwindow to $true or $false. However, this would break all scripts that assume on OPEN means a query window is being opened.

2) Add a new on OPEN event character, such as ~ tilde, that indicates a message window is being opened. This would break all scripts that make assumptions about available window types, eg. on OPEN * to intercept all window types.

3) Add a new on SMWINDOW event just for the message window. However, this would only trigger when the window is first opened. So if it is already open, your script would not be able to tell if on TEXT was being directed to it. So this might not be that useful.

4) Add a $smwindow identifier that returns $true/$false in the on TEXT event. This would indicate whether the text is being directed to the message window. This might be the best solution that does not break any existing scripts.

Joined: Jul 2006
Posts: 4,145
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
4) by itself would not solve raccoon's problem though, it would still be impossible to know if the message sent is the first one without scripting it ourselves.
However, 4) + a property like $smwindow.opened returning $true/$false if the single message window was opened because of that received text, would solve that issue.

Last edited by Wims; 25/02/17 01:52 PM. Reason: $smwindow.opened

#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Feb 2003
Posts: 2,812
Raccoon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
How about a $dqwindow identifier to compliment the /dqwindow command? Maybe 2 behaviors: Inside of a Text/Action query (or Open) event, it returns $true or $false to determine if the output will be sent to the "Message Window". Outside of an event, it returns $yes or $no to indicate the user preference is on/off.

Alternate suggestion: $query, without (), would return the valid window target in which the query is going to be displayed in. Eg: "#mIRC" if displayed in 'active window', "MadGoat" if to MadGoat's own query window, or "Messages" if sent to the Single Message Window / Dedicated Query window. Then people could use the code: /echo -ti $query Stuff $nick $1-.

(Might then have to make "Messages" a valid window alias to "Message Window", because it contains a space and would require $qt($query) in /echo commands. Strangely the switchbar says "Messages" but $active and $window() knows it as "Message Window". Same deal with "Status Window", maybe should just be "Status"?)

I agree, the whole thing is really pretty ambiguous because it has been this way for so long. I don't expect it'd be easy to fire an On Open event in the way I would expect it to when the user has Use Single Message Window enabled and the sender has sent a query for the first time. The buffer of the dqwindow would have to be read through to see if any previous messages were sent.

So I generally retract my bug report. It's not that important. There are too many overlapping behaviors to make a solution feasible or necessary.

P.S. While playing with mIRC's options to write this post, I seriously question whether "Show In Active:" [x]Queries, is working as intended. I'm not getting it to work at all anymore?


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Quote:
P.S. While playing with mIRC's options to write this post, I seriously question whether "Show In Active:" [x]Queries, is working as intended. I'm not getting it to work at all anymore?

Please do not post more than one bug report per thread :-] It makes it impossible to track bugs. If you are experiencing this and are able to reproduce it, please create a new thread.

Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
I could add a $dqwindow identifier that is only accessible in the on TEXT/ACTION events and returns: 1 if the message window is about to be opened and written to, or 2 if the message window is already open and is about to be written to. It returns 0 in all other cases. Would that help?

Joined: Feb 2003
Posts: 2,812
Raccoon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
That's not a bad solution. I would ask that $dqwindow outside of PRIVMSG events returns $true/$false for the user preference of /dqwindow being on or off, since there is no reference to this. But then I don't know if those two should overlap.

Up to you. smile


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
The overlap should be okay here since any non-zero value implies it is enabled ie. ($dqwindow == 1) means it is enabled, ($dqwindow == 2) means it is enabled, about to be opened and written to, and ($dqwindow == 3) means it is enabled, already open and about to be written to. This will be in the next beta.

Update: the more I look into it, the more contexts there are, eg. the message window is open but not currently enabled, or if halted in on ^text/^action, the window will not be opened or written to, which may be useful to know in the following on text/action, or /dqwindow may be used in on ^text/^action to change its on/off/show/hide state, and so on. However, the more contexts I add to $dqwindow, the more if comparisons you will need to make. Also, I will likely need to make $dqwindow use bitfields ie. ($dqwindow & 1) = enabled in IRC/Options, etc. to represent all of the contexts.

Update: I have whittled it down to the following states:

Code:
on ^*:TEXT:*:*:{
  echo 5 ^TEXT event
  dqwindowstate
}
on *:TEXT:*:*:{
  echo 5 TEXT event
  dqwindowstate
}
alias dqwindowstate {
  echo State: $iif($dqwindow & 1,enabled,not enabled)
  echo State: $iif($dqwindow & 2,open,not open)
  echo State: $iif($dqwindow & 4,opening,not opening)
  echo State: $iif($dqwindow & 8,writing,not writing)
  echo State: $iif($dqwindow & 16,written,not written)
}

Last edited by Khaled; 26/02/17 11:56 AM.

Link Copied to Clipboard