Forums General Discussion mIRC text selection bug

When you're trying to select part of text by mouse, all 100% of CPU time is going to be consumed.. therefore all time-critical applications got stuck (as TV-Tuner, Media player, WinAMP, etc)...
And for that reason personnaly ME got to write all this text that could be selected by my own hands, to not to hear or see CPU stuck problem .
This bug as I know is from very beginning of mIRC..

CPU = AMD 1600+
RAM = 512mb
Win2k
mIRC v6.12
AND
mIRC v6.03

in a popup channel with all the colors .. using ctrl + copy or just copy .. unable to select enough text to use up more than 40% of the CPU .. and that for less than 10 seconds (because I was deliberatly trying to be slow)

AMD Athlon 3200+ (barton)
512Mb PC3200
version 6.12
Windows XP Pro (SP1)
mediaplayer (xvid avi file).
simple channel window.
moving mouse inside text window. pushing LMB. [short stuck of avi]. slowly moving mouse down (LMB is still down). [cycle of huge number of short stucks of avi, in task manager number of 100% peaks]. LMB is still down, but CPU time consuming is low, and when mouse is moving - [stuck, stuck stuck]
Later I could drop a screenshot.

In 5.91 worst effect. when LMB is down - continuous stuck, when even mouse isn't moving. Version 6.03 and more get stucks only when moving mouse and LMB is down.

Added: IMHO Khaled's scheme: cyclically recalculate select range through windows buffer, mouse coords, when LMB is down. ON EVERY even 1px mouse pos change, and a lack of sleep(1); in that cycle.
Also when switching windows... stucks. maybe it's redraw(); problem? it s used in mouse selection routine, and in windows switching...
By the way, when script is running it also possible to get HUGE stuck over a 15 seconds. (loading of 400 last lines from log into the window). All windows applications are hung for that time and all mirc menus and icons are cleared for that time.

IMHO - serious problem in mIRC base code (quick draw option makes no difference in this stuck effect)

here is screenshot of task manager:

applications running: mirc, task manager.
if mirc window is small % consumed is not much. fullscreen makes it 100%.
Therefore IMHO it's redraw() problem, not mouse selection.

i only got it to use 25% , it went up to 100% when i moved a dialog around(slowly) though.

Could you provide us with a screenshot of the processes list in the task manager, sorted in order of CPU usage? Would possibly be more useful

Well, I still use 5.91 and it's actually not making a difference here.. consumes almost nothing, btw my pc is an old p3, 850mhz, 128mb ram, win98se.

Hey ppl, how'd you managed not to get that bug?
Do you guys ever watching AVI movies while chatting?
Me - yes...

as i mentioned above, further examination points on redraw(). It is very time'consuming function. And I guess - realtime.

Your copy of mIRC seems to be consuming much RAM. Are you in lots of channels with huge amounts of scroll-back text?

I have 4000 lined buffer on each window... about 5-10 windows (channel+privates).
And this CPU time consume process is only when redraw() procedure is called (switching channel/private windows, loading long file into window, selecting text by mouse).

Khaled must revise his draw procedure. Definatly.

Perhaps. Thing is tho, when I used Windows and mIRC, I never ever came across this issue, and none of the mIRC users I know have ever complained about it to me so this *seems* to be a unique issue presenting itself to you only. Unless someone else happens to report this, I'm gonna say the problem lies not with mIRC itself, but perhaps with something else

I must say that on my work (Intel P4 2.0GHz, 256 DDR) also have this problem. Even on a status screen only * /lusers: not connected to server appeared.
Maybe other ppl doesn't watch avi movies when selecting text from mirc? Or just don't pay much attention on single picture stuck when selecting.
Really strange that only me noticed this bug. And not only on my PC.

I've just attempted to select some text from mIRC while an AVI was being played. It's still fine, didn't stick. Your media player, perhaps? Mine isn't the most recent Windows Media Player, it's 7.01.00.3055 (didn't want to upgrade). DivX Player 2.1 also doesn't interfere here at all, so I really believe it's not only about mIRC.

I've just attemped to use pure mirc... and problem has gone! I suppose it's script specific bug...
But WHY script have any influence on mouse-selection routine? As I know, where LMB is pressed, even text doesn't scroll, so it's nearly realtime non interruptable process...

Hrmmmmmm................

Maybe too many timers activated at the time? I don't know, I suppose it could be a lot of things..

Try a smaller scroll buffer in your usual mIRC, like 500 lines, then type /clearall and wait a few minutes for the windows to fill up with a couple pages of text.

See if the CPU increases as the buffer fills, and if the CPU increases at larger buffer limits. Note that 4000 lines stores nearly 3 days worth of conversation in most chat channels.

- Raccoon