Forums Bug Reports switchbar issues

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.