mIRC Home    About    Download    Register    News    Help

Print Thread
Page 2 of 2 1 2
argv0 #201753 03/07/08 04:57 PM
Joined: Jul 2008
Posts: 2
Z
Bowl of petunias
Offline
Bowl of petunias
Z
Joined: Jul 2008
Posts: 2
Originally Posted By: argv0
Until then you can use this script to fix the behaviour:
Code:
on *:text:*:*:if ($iif($chan,$chan,$target) == $active) window -g0 $v1


Code:
on *:text:*:$($active):window -g0 $active
on *:action:*:$($active):window -g0 $active
on *:mode:$($active):window -g0 #
on *:join:$($active):window -g0 #
on *:part:$($active):window -g0 #

Khaled #201809 05/07/08 08:10 PM
Joined: Feb 2006
Posts: 74
G
gbz Offline OP
Babel fish
OP Offline
Babel fish
G
Joined: Feb 2006
Posts: 74
Originally Posted By: Khaled
I'll try it the next time there's a Windows update available

I've come across another way to reproduce this more easily.

- Lock the computer (Windows key + L) while mIRC is the active app
- Reset your connection so mIRC reconnects
- Unlock the computer

Note: You'll have to actually reset your internet connection to trigger the reconnect. A test with a timed /server didn't produce the issue here.

zl0h #201824 06/07/08 02:32 PM
Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
There's no need for $($active) and I'm not sure that will even work. Just use * or # respectively.

hixxy #201828 06/07/08 04:21 PM
Joined: Jul 2008
Posts: 2
Z
Bowl of petunias
Offline
Bowl of petunias
Z
Joined: Jul 2008
Posts: 2
Sure it works, this is what $() was made for, why would you use * or # and then check if $chan is the active channel?

zl0h #201831 06/07/08 05:18 PM
Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
I seem to recall that $(...) didn't use to work in target parameters of events but only the matchtext sections (ie. on *:text:$(...):#: would work but on *:text:*:$(...): wouldn't) - either I'm imagining it or it's been fixed, so disregard my post.

I also misunderstood what the script was doing.

Khaled #202467 23/07/08 01:55 AM
Joined: Feb 2006
Posts: 74
G
gbz Offline OP
Babel fish
OP Offline
Babel fish
G
Joined: Feb 2006
Posts: 74
Originally Posted By: Khaled
I'll try to resolve this for the next version.

Thanks for fixing the channels list window issue smile

Update on the highlight issue: It's still happening in 6.33, always somehow related to disconnects/reconnects (and possibly mIRC being inactive during them). As said in my previous post, locking the computer and resetting your internet connection reproduces it very reliably.

Another note, though I don't know if it helps: When the issue occurs, one way to get rid of the highlight is to right-click into the window to bring up its context menu, then click into another area of the window so it closes. The moment the second click is performed, the highlight is removed. None of the events from your script trigger when doing this though.

Khaled #203618 21/08/08 06:00 PM
Joined: Feb 2006
Posts: 74
G
gbz Offline OP
Babel fish
OP Offline
Babel fish
G
Joined: Feb 2006
Posts: 74
Ok, it took some time, but I finally found out what's really causing the focussing issue: It's the channels list window. Besides rejoining channels on reconnect, I had a /list in my perform section. I never thought this would matter, but now I know it does. There are actually 3 issues as it is, so I'll list them all.

1. The original issue described in this thread, now simply reproducible as follows:

- do //.timer 1 3 list | .timer 1 3 join #somechan
- before the timer fires, click on an empty spot on the windows taskbar to deactivate mIRC

You'll notice that the moment /list is executed, mIRC starts thinking it's active again when it's not (you can tell this by the titlebar color). The button of the channel that was joined via timer is highlighted and now remains highlighted even after you activate mIRC again.

2. Related: In the above scenario you'll also notice that the channels list window button is highlighted even though its not mIRC's active window, which I believe is wrong as well since that window is never updated when it's not on top (whenever you request a /list it's brought to the top first).

3. While playing around with all this, I came across another focussing bug which apparently was found by someone else on this board as well and mentioned a few days ago in mIRC Help. Reproduction:

- do /.timer 1 3 join #somechan
- before the timer fires, click on an empty spot on the windows taskbar to deactivate mIRC

You'll notice that even though the channel is joined properly and brought to the top, the switchbar isn't updated accordingly. It still shows the previous window's button as active and is only updated once you activate mIRC again.

gbz #203667 23/08/08 08:51 PM
Joined: Feb 2006
Posts: 74
G
gbz Offline OP
Babel fish
OP Offline
Babel fish
G
Joined: Feb 2006
Posts: 74
Sorry, have to add something I noticed just now: In order to reproduce issue #1 it is important that the channels list window is already open before performing the reproduction steps, else the results differ.

gbz #224143 05/08/10 06:49 PM
Joined: Feb 2006
Posts: 74
G
gbz Offline OP
Babel fish
OP Offline
Babel fish
G
Joined: Feb 2006
Posts: 74
Update: The bugs described in this thread are still present in mIRC 7.1.

My previous posts from 2 years ago probably got a bit confusing since I didn't have reliable reproduction steps for a while, so I'll just summarize the issues again and provide reproduction steps that I verified work in a vanilla mIRC 7.1.

Bug 1: mIRC showing as active when it isn't + incorrect button highlighting

Reproduction:

- do a /list and keep the channels list window open
- Put //.timer 1 3 list | .timer 1 3 join #somechan in the editbox and hit enter
- before the timer fires, click on an empty spot on the windows taskbar so mIRC is not the active window anymore

Result: mIRC's titlebar color changes to indicate that it's the active application, even though by taskbar state it is not. The button of the channel that was joined via timer is highlighted and now remains highlighted even after you activate mIRC again.

Bug 2: Switchbar not being updated while mIRC isn't active

Reproduction:

- Put /.timer 1 3 join #somechan in the editbox and hit enter
- before the timer fires, click on an empty spot on the windows taskbar to deactivate mIRC

Result: The channel is joined properly and brought to the top, but the switchbar isn't updated accordingly: It still shows the previous window's button as active and is only updated once you make mIRC the active application again.

gbz #224295 08/08/10 10:48 AM
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Bug 1: I was unable to reproduce this. None of the mIRC window titlebars are shown as active and the highlighting is correct. If you place mirc.exe and an empty mirc.ini in an empty folder and test from there, does it still happen? Changing any settings, or even maximizing windows, can make a difference to the result.

Bug 2: All focus-related features/scripts in mIRC are directly dependent on Windows focus messages, so the reason for this behaviour is that Windows has not sent any focus messages to mIRC since it is not the active application. Focus messages are the only reliable method of determining whether a button should be pressed. For example, it is possible for a window below the top window to have the focus, so window position in the display order is not a valid method of determing whether a button should be pressed or not. Windows can open minimized, behind other windows, on the desktop, and so on. Changing the switchbar button display to work independently of focus events would result in the switchbar not being synchronized with focus messages, such as highlighting, scripts, and other focus events.

Khaled #224336 09/08/10 12:56 AM
Joined: Feb 2006
Posts: 74
G
gbz Offline OP
Babel fish
OP Offline
Babel fish
G
Joined: Feb 2006
Posts: 74
Thanks for the explanation regarding the second issue. smile

As for the first one:

Originally Posted By: Khaled
If you place mirc.exe and an empty mirc.ini in an empty folder and test from there, does it still happen? Changing any settings, or even maximizing windows, can make a difference to the result.

I tested with just mirc.exe and an empty mirc.ini, but I did maximize the status window before connecting, so I tried again now without even doing that. Result: The titlebar does not change to active after the timer fires; so in order to reproduce that part of the bug, it is necessary to maximize the status window prior to following the reproduction steps.

The highlighting issue occurs either way though, so I'm not sure why you can't reproduce it. Did you open the channels list window and keep it open before starting the timers? Just making sure since I actually forgot that step earlier and was wondering why I couldn't reproduce the bug anymore.

To clarify, here's what I do after following the reproduction steps:

- I click into the newly opened channel to make mIRC the active application again.
- The text on the channel's switchbar button remains blue, so the event highlight from the /join is not removed even though both mIRC and the channel window are active now.
- If I move the mouse over that channel's switchbar button, it is raised.
- If I type a message in the channel and send it, the switchbar button's text turns red (message highlight) even though I sent the message from that very window.

gbz #224362 09/08/10 01:24 PM
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Quote:
mIRC's titlebar color changes to indicate that it's the active application, even though by taskbar state it is not.

I have not been able to reproduce the above issue so far. The titlebar color is actually controlled by Windows, so it looks like Windows is getting confused in this situation. It may be due to a combination of how mIRC is setting the window focus and/or your Windows settings.

Quote:
The button of the channel that was joined via timer is highlighted and now remains highlighted even after you activate mIRC again

I have been able to reproduce the above issue. Focusing is a tricky problem - it triggers a whole range of features - and one small change in the focus routine work can result a number of side-effects. I have made a change that should resolve it but will need more testing before it makes it into the next version.

Khaled #226231 23/09/10 07:08 PM
Joined: Feb 2006
Posts: 74
G
gbz Offline OP
Babel fish
OP Offline
Babel fish
G
Joined: Feb 2006
Posts: 74
Just tested this with v7.11. The highlighting bug is fixed!

Also, it seems the change you made got rid of the titlebar/active app issue that you couldn't reproduce as well.

Many thanks! smile

Page 2 of 2 1 2

Link Copied to Clipboard