Bug #5778
open"Open Window on /msg" doesn't do anything, windows are still opened when this is disabled
Added by Tomasz Nowak about 1 year ago. Updated about 1 year ago.
0%
Description
As per documentation:
"If the message is to a nick and "Open Window on /msg" option is enabled, a private window with that nick will be opened if necessary."
I have disabled this option but still new windows is being opened when /msg nick message someone.
Please fix, thanks!
Updated by Tomasz Nowak about 1 year ago
Hello Per,
To my understanding this option when enabled opens a new query window if you type /msg <nick> <message> command, and when disabled it sends the privmsg without opening a new query window. In my testing this option doesn't make any difference, with either enabled or disabled, it always opens a new query window. I'm using ZNC, but also connected to plain network to make sure my ZNC configuration is not a factor here.
Are you sure you can't reproduce this? I'm using version 4.4 64-bit on Win 10. If there is any additional info you require please let me know. I can even record a video if that helps.
Thanks.
Updated by Per Amundsen about 1 year ago
That is correct, although if the person replies, it will open a new window with the reply.
All I can think of, is duplicate entries of the option in the config.ini file, look for "OpenWinMsg=True/False".
Another unlikely issue could be an alias that overrides the built-in /msg command, maybe check for that as well.
Updated by Tomasz Nowak about 1 year ago
I just tested this again in plain IRC connection without bouncer and it does indeed open a new query window on /msg even if the target does not send a reply. I have checked all my scripts/aliases and nothing there interfering with /msg, also my config and only have one occurence of OpenWinMsg=False but also found OpenWinPriv=True right after it, is that related?
Updated by Per Amundsen about 1 year ago
No, "OpenWinPriv" is for opening a private window on a reply, the option text is "Open new window on private window".
This is very puzzling, what happens if you copy your AdiIRC.exe to a folder on your desktop or something, then run it from there and disable the option?
Updated by Tomasz Nowak about 1 year ago
OK, so I downloaded portable version and it was behaving as intended, so digging further I figured out that when echo-message is enabled in IRCv3 settings then that opens a query when you use /msg command. So there's your bug in echo-message implementation.
What I'm trying to achieve here is that when I close a query window, a script sends /msg *status clearbuffer $target to clear the ZNC query buffer for that query so it doesn't get replayed next time I connect to my ZNC, and then suppress the response from *status so this whole thing is invisible. I made the following simple script:
on 1:CLOSE:?:if ($regex(query, $target, ^\*.*) == 0) { /msg *status clearbuffer $target }
on ^:TEXT:*buffer*matching:?:{
echo -s ZNC clearbuffer message supressed for query with: $target
haltdef
}
It will intercept and display echo in server window, but still opens up an empty query window with *status. What am I doing wrong here?
Updated by Per Amundsen about 1 year ago
I see, the echo-message support is a little shaky since there are a lot to consider, it also currently behaves different than in mirc. In mirc the reply generates events such as on TEXT on the echoed message while adiirc does not.
I am working on making it more similar to mirc while also adding some options, this should fix this issue as well.
For now you can try replacing /msg with "/raw PRIVMSG <nick> :text", I don't think that will generate a echo reply, if it does, you could use on PARSELINE to try and catch the reply and halt it.
Updated by Per Amundsen about 1 year ago
Actually, I think you can continue using /msg and then use on PARSELINE to catch the "buffer matching" message, then halt it with something like: /parseline -it $null
Updated by Tomasz Nowak about 1 year ago
Makes no difference whether you use /msg or /raw privmsg - results are the same. I got it working by disabling echo-messages on all ZNC connected servers, adding script from https://blog.jay2k1.com/2016/09/11/how-to-make-mirc-compatible-with-zncs-znc-inself-message-cap/ to make sure I still get my own messages in replayed query buffers, and then using your suggestion with on PARSELINE. Looking forward to future versions for fixes :-) Thanks for your help.
Updated by Per Amundsen about 1 year ago
I should probably have clarified you would have to capture the echoed "status clearbuffer" message with on PARSELINE and halt it, since that is the one opening the window.
Glad you find a solution for now, I use the same script, it's great.
Updated by Tomasz Nowak about 1 year ago
on 1:CLOSE:?:if ($regex(query, $target, ^\*.*) == 0) { /raw privmsg status :clearbuffer $target | halt }
on *:PARSELINE:in:*buffer*matching:echo -s message $parseline suppressed | /parseline -it $null
I have it like that, is this what you mean?
Updated by Per Amundsen about 1 year ago
Something like this:
on 1:CLOSE:?:if ($regex(query, $target, ^\*.*) == 0) { /raw privmsg *status :clearbuffer $target | halt } ; halt the echoed "/msg *status clearbuffer <target>" message which is the one opening the window on *:PARSELINE:in:*status*clearbuffer*:/parseline -it $null
I think you should then be able to use the regular on TEXT for the buffer matching message which is not a echoed message.
Updated by Tomasz Nowak about 1 year ago
Any way to stop "Parseline in:" showing up in the server window?
Updated by Per Amundsen about 1 year ago
Prefix the command with "." /.parseline
Updated by Tomasz Nowak about 1 year ago
Perfect, now it all works silently :-) Thanks for all the help, much appreciated!