1. Some switchbar buttons display a tooltip on mouse over, others don't. This applies to (seemingly random) channel and query buttons, probably other window types as well.

2. Since v6.3, the active window's switchbar button is highlighted on activity if mIRC is not the active application. When mIRC becomes active again, the highlight is removed...unless another application opens a window by itself.
Example: mIRC is active when an IM window pops up. If you close that IM window now, mIRC becomes the active app again, but the active switchbar button remains highlighted and stays that way until you issue a command or switch to another window.

1) There should only be a tooltip if the entire window name is not displayed, if you can see the entire channel name then there should be no tooltip.

2) This has been reported and according to the replies it is intended behavior.

1. Yeah you are right. Somehow I never noticed it only happens for those buttons that don't display the full window name. Too used to them getting cut off I guess.

2. I searched again but can't seem to find this mentioned anywhere before. I know there was a thread about switchbar buttons (started by me) which explains a lot of the changes to switchbar behaviour implemented in 6.3, but it doesn't deal with this specific issue of highlight not being reset when mIRC is in focus again. Can you provide a link to the thread you're thinking of?

I found your thread, is it not the same issue?

No. Related to it, but not the same issue.
The highlight for mIRC's active window is usually removed the moment mIRC is in focus again. I was pointing out that this doesn't happen if you close a window you didn't open yourself, e.g. an IM window popping up when someone messages you.

Normal behaviour:
- mIRC is active
- you open some other application
- you close that app so the previous one (mIRC) is active again
- highlight for mIRC's active window is removed

Inconsistency:
- mIRC is active
- some other application opens a window by itself
- you close that app so the previous one (mIRC) is active again
- highlight for mIRC's active window is not removed

Hope it's clearer now.

Yes. I can confirm this.

It's been bugging me since 6.3 as well, but I never thought enough of it to post a bug report. To *me*, this is not what I'd expect mIRC to do. My OCD always ends up having me click the channel in the switchbar to remove the highlight state even though the window is still active-- it can get annoying sometimes.

To clarify though, another window doesn't have to open by itself, you just need to have another application window other than mIRC active. Then, if the highlight state for the active switchbar item changes during that time, it will remain that way when mIRC is reactivated.

Glad someone can confirm this. Unlike you, I am unable to reproduce it with applications I opened manually though.

Test: I open Winamp over mIRC. Highlight of the active switchbar item in mIRC is removed if I...
- close Winamp
- click on its taskbar button to deselect it
- select mIRC in the windows taskbar
- reactivate mIRC by clicking into its window
- jump to mIRC using Alt+Tab

Win XP Pro SP2

You're right. I don't know what situation I was thinking of. I'll pay more attention next time it happens, but I remember it happened more often than just for windows that stole focus from mirc on their own

To clarify, is this the behaviour you're talking about?

Assuming mIRC was active and scripts editor, options etc. weren't open when that was taken, yes.

Found another issue related to this one:

If the channels list window is open and a new list is requested via the toolbar button while in another window, the list appears but its switchbar button isn't activated. The previous window's button remains active while the channels list button is highlighted. Clicking on it to activate it simply does nothing. If the previous window's button is clicked, it is raised as if that window was still in the foreground.

Update: The original switchbar issue discussed here as well as the one I brought up in my previous post are still present in 6.32.

Since we had a screenshot for the first issue in this thread, I decided to add one for the second as well, to make it clearer what I'm talking about.

Important note on reproducing the second bug: I just discovered this works fine when typing /list; the issue only appears when clicking Channels List in the toolbar, then Get List! in the dialog. And as said, the list window must already be open when doing this.

Sorry, I always use the button, so I didn't notice this earlier.

Apparently the original switchbar in this topic issue was deemed an intentional change. The expected behaviour is now to highlight the active mIRC window when mIRC itself is not the active application regardless if it is the active *mIRC* window. This is because the assumption is that if mIRC is not active then another window is likely hiding the mIRC window and if it did not go red most users would not know about activity. If you think about it in that sense, the change seems reasonable. Basically, until more people start getting dual monitors or larger screens, this behaviour is likely to stay in order to benefit the majority of users that probably lose sight of mIRC when it goes inactive.

Until then you can use this script to fix the behaviour:

I'm not sure if I understood that part right, but if I do, we are talking about different extents of this issue: I am aware that mIRC's active window being highlighted when mIRC is inactive is intended; this was discussed in another thread that RoCk linked in this one on page 1.
The issue I've been on about here the whole time is that that highlight is not removed when mIRC becomes active again in certain situations; namely if some other window stole focus from it on its own.
As said on page 1: If you manually open some smaller window over mIRC (like Winamp), you can see mIRC's active window being highlighted on activity in the background. When you close that other window, mIRC becomes the active app again and that highlight is removed. I think that's how it was meant to be. But: If an IM or something else you didn't initiate yourself pops up over mIRC and you close that, mIRC still becomes active again but the highlight stays.

Thanks the channels list window issue has been fixed for the next version.

I have not been able to reproduce the button highlight issue so far. I used the following script to monitor activation events:

on 1:APPACTIVE:echo APPACTIVE appactive: $appactive
on 1:ACTIVE:*:echo ACTIVE active: $active

mIRC should always show the above events when it is activated and deactivated - they are directly linked to the way highlighting works.

If you use the above script, do you notice any difference in triggered events in the two situations that you described?

Can you describe a step by step method that reproduces it for you that I can use to reproduce it here?

Yes. When switching between apps and all goes well, your script returns:

APPACTIVE appactive: $false
APPACTIVE appactive: $true
ACTIVE active: Status Window

When the issue appears, the order of events changes:

APPACTIVE appactive: $false
ACTIVE active: Status Window
APPACTIVE appactive: $true

Now that order also appears at times when the issue doesn't. But whenever the issue appears, that order does too.

As said, reproducing this is somewhat tricky. I've come up with a way that works most of the time, but it requires having the windows update notification icon in the system tray (or probably anything else that pops up a window with a slight delay).

- Click on the icon while mIRC is active (causes APPACTIVE appactive: $false)
- During the delay before the update dialog pops up, click into mIRC's window to reactivate it (causes ACTIVE active: Status Window)
- When the dialog has opened, click Cancel to close it, which will reactivate mIRC (causes APPACTIVE appactive: $true)

Of course I usually encounter the issue under different circumstances, but none of them reproduce it as reliably as the above (about 4 out of 5 times).

Thanks, I haven't been able to reproduce this yet - I'll try it the next time there's a Windows update available - however I think I can see why this particular issue is happening. The way window activation/deactivation is handled in mIRC is complicated - it has to cater for a range of special cases and timings relating to how Windows works with different settings. I'll try to resolve this for the next version.

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.

There's no need for $($active) and I'm not sure that will even work. Just use * or # respectively.

Sure it works, this is what $() was made for, why would you use * or # and then check if $chan is the active channel?

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.

Thanks for fixing the channels list window issue

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.

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.

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.

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.

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.

Thanks for the explanation regarding the second issue.

As for the first one:


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.

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.


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.

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!