|
Joined: Aug 2006
Posts: 167
Vogon poet
|
OP
Vogon poet
Joined: Aug 2006
Posts: 167 |
Found in 7.22, still in 7.23. To reproduce, start from a clean install and only alter it thusly:
ALT-O > IRC > [ ] Minimize query window ALT-O > IRC > Show in active: [x] Away [ ] Whois
1) Typing "/whois Bob" in a /query window to Bob causes the /whois response to appear in your status window (as expected based on the configuration above), except for its "Bob is away: <reason>" line, which alone gets displayed in your /query window to Bob. This appears to be a bug, since if you type "/whois Bob" in any other window, including in a query window to someone else, the "Bob is away: <reason>" line will appear in your status window along with the rest of the /whois reply's lines. (In any case, I would assume mIRC would want to contextualize the away line as a part of a /whois reply and not scatter the reply's total output between separate windows.)
2) Connect to the same server in two server windows with different nicks. Open a query window in the first connection to the nick of the second connection. Then type something in that window. A new query window (belonging to the other nick) will open, taking focus. By taking focus, mIRC is confused into dumping the server's "Bob is away: <reason>" line into your status window rather than into the original query window, where it actually should appear. (For comparison, when [x] Minimize query window is checked, causing the other query window to open minimized, the aforementioned away line will appear as expected in the original query window as soon as you send your first message.)
3) "/window -De @blah", then "/echo @blah This is a font test", then change @blah's font to something else. Then set @blah to On Desktop. When you do, the window's font reverts to the font it originally opened with. (Also happens if you change the font again, and uncheck "On Desktop.")
4) Background image/wallpaper for treebar area does not work. The image seems to appear in the divider bar, but the treebar area itself shows nothing, as if a flat color area is overlaid atop the image itself. (Note: the treebar's background menu also doesn't let you choose center|fill|normal|stretch|tile|photo, as all other parts of mIRC do for backgrounds.)
|
|
|
|
Joined: Oct 2004
Posts: 8,330
Hoopy frood
|
Hoopy frood
Joined: Oct 2004
Posts: 8,330 |
I haven't looked into the first 3, but #4 isn't a bug. It's just the way it's designed. It's been requested before to have more control over filling the treebar, but this is just how it was set up when the treebar was created and has not yet been changed.
Invision Support #Invision on irc.irchighway.net
|
|
|
|
Joined: Aug 2006
Posts: 167
Vogon poet
|
OP
Vogon poet
Joined: Aug 2006
Posts: 167 |
Well, here's how I saw it. In mIRC, the MDI, the toolbar, the switchbar, and every type of window can be given a background wallpaper that completely fills its respective inner surface area. If the treebar didn't offer background image selection, then that would be a simple inconsistency and nothing more than a potential feature request. But fitting the pattern that exists everywhere else, background image selection is in fact clearly offered for the treebar area, both via the menu option you get for it when right-clicking inside the treebar area, and by "/background -b", which is explicitly documented as being for filling the treebar. That said, when instead of filling that area the image fills a tiny 4 pixel-wide divider adjacent to it, I get a very clear impression that the issue is in fact a bug -- one consisting of the source code's background() function mistakenly targeting the wrong GUI object. Another reason: it doesn't make sense that Khaled would have purposely decided against giving the treebar background image support, yet in favor of giving background image support to its 4 pixel-wide divider -- something inherently so narrow that it doesn't even let you make out what's in the selected image.
|
|
|
|
Joined: Oct 2004
Posts: 8,330
Hoopy frood
|
Hoopy frood
Joined: Oct 2004
Posts: 8,330 |
I understand your thought on this, but if you follow how it has worked since the treebar was created and the topics regarding it, you'll see that it is by design. The switchbar buttons are similar. I do think the user should be able to theme it the way they want, but that doesn't make it a bug. A bug is unintended behavior, but this was done on purpose.
Invision Support #Invision on irc.irchighway.net
|
|
|
|
Joined: Dec 2002
Posts: 5,477
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,477 |
Thanks - items one and three have been fixed for the next version. I was not able to reproduce item two. Item four is by design. Please remember to post each bug report or feature suggestion in its own post. When multiple reports/suggestions are posted together, it becomes difficult to follow the discussion thread and track the status of each item.
|
|
|
|
Joined: Aug 2006
Posts: 167
Vogon poet
|
OP
Vogon poet
Joined: Aug 2006
Posts: 167 |
Item 2: oops, sorry, I left out a detail. I'll start over (see bold):
1) Clean install. 2) ALT-O > IRC > [ ] Minimize query window 3) ALT-O > IRC > Show in active: [x] Away 4) ALT-O > IRC > Show in active: [ ] Whois 5) Connect to a server as Nick1 6) Open a second server window 7) Connect that new server window to the same server as Nick2 8) In the second server window: /away I'm not here... 9) From first server window: /query Nick1 10) Type something in Nick1 query window 11) Nick2's away reason does not appear in query window as expected: appears in status window instead
If the same process is repeated without step 2, the bug does not occur.
|
|
|
|
Joined: Aug 2006
Posts: 167
Vogon poet
|
OP
Vogon poet
Joined: Aug 2006
Posts: 167 |
Sigh, I can't seem to get this one right. Correcting errors in post above (can no longer edit it):
1) Clean install. 2) ALT-O > IRC > [ ] Minimize query window 3) ALT-O > IRC > Show in active: [x] Away 4) ALT-O > IRC > Show in active: [ ] Whois 5) Connect to a server as Nick1 6) Open a second server window 7) Connect that new server window to the same server as Nick2 8) In the second server window: /away I'm not here... 9) From first server window: /query Nick2 10) Type something in Nick2 query window 11) Nick2's away reason does not appear in query window as expected: appears in status window instead
If the same process is repeated without step 2, the bug does not occur.
|
|
|
|
Joined: Aug 2006
Posts: 167
Vogon poet
|
OP
Vogon poet
Joined: Aug 2006
Posts: 167 |
Bugs 1 and 3 were fixed, but not this one (#2). I already have 7.24 and it's still there.
|
|
|
|
Joined: Dec 2002
Posts: 344
Pan-dimensional mouse
|
Pan-dimensional mouse
Joined: Dec 2002
Posts: 344 |
Bugs 1 and 3 were fixed, but not this one (#2). I already have 7.24 and it's still there. Please double check that you are using the correct version. I just followed your steps exactly with 7.24 and the bug does NOT occur. The away message is displayed in the query window, not in the status window.
|
|
|
|
Joined: Aug 2006
Posts: 167
Vogon poet
|
OP
Vogon poet
Joined: Aug 2006
Posts: 167 |
Okay, I'm confused. I tried it yet again, but on a different server. This time, it didn't occur. But going back to the original server I was using, it did happen there again. Yet when I compare both servers, I cannot find any differences in what's happening under the hood at either the /debug level or at the packet sniffer level. ?! See if you can reproduce it yourself. It happens on evergreen.irc.simpworks.com:6667 but not on tampa.fl.us.undernet.org:6667 /debug comparison: -> evergreen.irc.simpworks.com PRIVMSG Nick002 :Testing...
<- :evergreen.irc.simpworks.com 301 Nick001 Nick002 :I'm gone...
-> Tampa.FL.US.Undernet.org PRIVMSG Nick002 :Testing...
<- :Tampa.FL.US.Undernet.org 301 Nick001 Nick002 :I'm gone... Packet sniffer comparison (plaintext, commands shown in order sent and received): PRIVMSG Nick002 :Testing...
:Nick001!root@pool-71-177-xx-xx.xxxxxx.xxxx.verizon.net PRIVMSG Nick002 :Testing...
:evergreen.irc.simpworks.com 301 Nick001 Nick002 :I'm gone...
PRIVMSG Nick002 :Testing...
:Nick001!root@pool-71-177-xx-xx.xxxxxx.xxxx.verizon.net PRIVMSG Nick002 :Testing...
:Tampa.FL.US.Undernet.org 301 Nick001 Nick002 :I'm gone... Edit: screen capture: http://img152.imageshack.us/img152/1130/examplefb.png
Last edited by pishposh; 27/05/12 10:06 AM.
|
|
|
|
Joined: Dec 2002
Posts: 344
Pan-dimensional mouse
|
Pan-dimensional mouse
Joined: Dec 2002
Posts: 344 |
Okay, I'm confused. I tried it yet again, but on a different server. This time, it didn't occur. But going back to the original server I was using, it did happen there again. Yet when I compare both servers, I cannot find any differences in what's happening under the hood at either the /debug level or at the packet sniffer level. ?! Yes, I can reproduce this. It seems to be based on some internal state being set after connecting to that server that never gets cleared. For example, once you /WHOIS anyone on the simpworks.com server, the away message will start to appear in the query window as expected.
|
|
|
|
Joined: Dec 2002
Posts: 5,477
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,477 |
What you are seeing is due to timing. When you send your message, if the server replies quickly, the second query window will open and be the active window before the away reply is received, so the away reply is displayed in the status window. If the away reply is received before the second query window opens, your current query window will be active and the away reply will be displayed there. This type of timing issue is more apparent when features that depend on the active window, and open windows themselves, are tested in the same client.
|
|
|
|
Joined: Aug 2006
Posts: 167
Vogon poet
|
OP
Vogon poet
Joined: Aug 2006
Posts: 167 |
Yeah, you're right. I tried confirming what drum discovered with /whois, but what he experienced didn't happen to me. So I took another look with my packet sniffer, and this time, I got: PRIVMSG Nick002 :Testing...
:Nick001!root@pool-71-177-xx-xx.xxxxxx.xxxx.verizon.net PRIVMSG Nick002 :Testing...
:evergreen.irc.simpworks.com 301 Nick001 Nick002 :I'm gone...
PRIVMSG Nick002 :Testing...
:Tampa.FL.US.Undernet.org 301 Nick001 Nick002 :I'm gone...
:Nick001!root@pool-71-177-xx-xx.xxxxxx.xxxx.verizon.net PRIVMSG Nick002 :Testing... I guess the first time, when I saw the same packet order from both servers, I was seeing out-of-order arrival. Should have checked the sequence numbers... So it's a daemon issue (if it's an issue at all). Sorry for the false alarm.
|
|
|
|
Joined: Dec 2002
Posts: 344
Pan-dimensional mouse
|
Pan-dimensional mouse
Joined: Dec 2002
Posts: 344 |
Yep, I should have tested more thoroughly. What Khaled is saying definitely seems correct now that I've tried it again.
|
|
|
|
|