mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Apr 2010
Posts: 59
A
Babel fish
OP Offline
Babel fish
A
Joined: Apr 2010
Posts: 59
Hello,

The channel window does not scroll forward when new messages arrive, if the channel menu is open with a nick selected.

Repro steps:
1) Join a test channel with two nicks.
2) With one nick, send a message, ten repetitions every five seconds: /timer 10 5 msg #[the channel] testing
3) With the second nick, right click on the first nick when it appears, leaving the menu open. The window does not advance the next time the first nick sends the message. The scroll bar shows the message arrived, but the window is frozen.

Particularly with script commands, new messages should be visible while you're looking through the channel menu. Users that need to see the original nick and line when it might scroll off the screen, can create a disabled menu item which shows that information.

Joined: Jun 2007
Posts: 933
5
Hoopy frood
Offline
Hoopy frood
5
Joined: Jun 2007
Posts: 933
Confirmed.
Note that this relates to the channel popup, not the nick list popup.

Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Thanks for your bug report. The current behaviour is by design and is not a bug. The right-click popup menu was designed to work this way and has done so for as long as I can remember. You will see the same behaviour for any right-click popup menus that work on hotlinks.

Joined: Apr 2010
Posts: 59
A
Babel fish
OP Offline
Babel fish
A
Joined: Apr 2010
Posts: 59
Hi Khaled,

Thanks for your reply, and nice to hear from you. I've only used mIRC for a few years, so I'm uninformed. What is the benefit of freezing the channel when a nick is clicked on?

IMHO, the channel should only be frozen by scrolling up to see previous messages, and therefore the current behavior is a bug.

What is the workaround to obtain the normal behavior please?

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
The benefit is that the window doesnt scroll as you are trying to select a menu item based on the nickname you right clicked on. If the window scrolled off after you right clicked a nick, you would no longer be able to confirm what it is you had right clicked on. I personally wouldn't trust clicking "Op" on a nick if I couldn't see the nick I had clicked on behind my mouse. Popups don't show the nick, so context relies on where the popup is in relation to your buffer at the time of click.

If it's designed this way, there is unlikely to be any workaround.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Apr 2010
Posts: 59
A
Babel fish
OP Offline
Babel fish
A
Joined: Apr 2010
Posts: 59
Perhaps this thread should be postponed to the "Feature Requests" forum. The forum staff have my permission as the OP to move it if you wish; I will check there.

Thanks argv0 for your explanation. Being able to see new messages is important. If you are going to kick someone, but they apologize in their next message, and your window is frozen, you won't know he or she apologized. Perhaps kicks and apologies are both more rare than I'm estimating.

I would be satisfied with either workaround, either unfreezing the window with an option in the channel menu, or freezing it with an option. The entire menu is reevaluated every time it's opened currently. Therefore, if you choose to freeze the window, either with the option or if it stays the default, you can print the nick that was clicked on as a disabled menu item, as follows:

Code:
menu nicklist,query,channel {
  $$1 #
}

IMHO the "reevaluate" step is also incorrect. Perhaps the nick or channel could be an item by default if it's changed.

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Originally Posted By: ascription
Thanks argv0 for your explanation. Being able to see new messages is important. If you are going to kick someone, but they apologize in their next message, and your window is frozen, you won't know he or she apologized. Perhaps kicks and apologies are both more rare than I'm estimating.


Accidentally kicking someone because they "apologized" too late is much less of an issue than trying to right click on a nickname during an enormous message flood to kick a user.. or trying to op a user only to realize you clicked on the wrong name because your window scrolled.

The evaluation behaviour is correct, by the way. It would be at least a million times worse if the target could change after showing the popup.

As for options, Khaled had previously pointed out that he's trying to pair down the amount of trivial visual options mIRC presents rather than add more. I can't speak for him, but I personally don't think we need to add a toggle switch for every single visual change in mIRC. The application behaves the way it does... rather than trying to fight it, perhaps you should look for another way to do what it is you want to do within the constraints of the program you're using. Not keeping popups open for minutes at a time would be a good start. That way channels won't start scrolling while you are deciding what it is you want to do. And if you really do want a more modeless behaviour, use a HOTLINK script to open a @window at your mouse on an rclick instead of relying on popups at all.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Apr 2010
Posts: 59
A
Babel fish
OP Offline
Babel fish
A
Joined: Apr 2010
Posts: 59
Argv0,

Quote:
Accidentally kicking someone because they "apologized" too late

The fact the person apologized too late isn't the *reason* he or she was kicked. The *reason* is that the admins felt threatened for any number of real or imaginary reasons or wanted a thrill. I will take your word for it that apologies don't happen much, but that doesn't affect the behavior of the window.

Quote:
trying to right click on a nickname during an enormous message flood

That is not a problem with the channel menu. That happens *before* you click; I was discussing what happens *after* you click. You can scroll up, and the window will freeze anyway. And you can click anywhere in the window; the fact one name is on the bottom line doesn't mean that you clicked on it.

Quote:
worse if the target could change after showing the popup.

New messages don't change the '$1' variable, whether the window is frozen or not.

Quote:
trying to op a user only to realize you clicked on the wrong name

The channel menu doesn't tell you what name you clicked on, whether the window is frozen or not, but perhaps it could. If the evaluation behavior stays, you can add "$$1" to the menu in gray, or the name could be added to the menu by default.

The evaluation behavior is not incorrect or correct; that's a matter of opinion. Long routines to generate text can sometimes be run ahead of time, and if they can't, then they require reevaluation by definition. It could also be useful for executing additional when the menu is opened. My objection was, in the case of large static menus, evaluation is slow, but that might be rare. To solve that, perhaps evaluation could only be performed on lines that have variables or aliases, and not static text.

Perhaps we need options for the pop-up menus, but without polluting the GUI. Script options could accomplish that. One option toggles display of the nick and channel that were clicked, another toggles freezing, and another toggles reevaluation behavior, as follows:
Code:
menu nicklist,query,channel {
  option show_name_in_menu 1
  option freeze_window 1
  option evaluate_menu 0
}

I'm not the engineer; distinguishing these commands from normal menu text might require special symbols.

Quote:
Khaled ... [is] trying to pair down the amount of trivial visual options

That's not unreasonable, but it does have a cost to the users. Perhaps these options could be script options only, and omitted from the GUI.

*"pare down", by the way, like "compare" and "prepare".

Quote:
Not keeping popups open for minutes at a time would be a good start.

...Unless you click on the channel and not a nick, that is, because otherwise a few minutes is fine and it's not a problem. You are trying to convince people that I don't want a different behavior.

I didn't study the 'HOTLINK' event closely. Can you pop up a menu? Does it freeze the window?


Link Copied to Clipboard