Its buggin me for a while now, so i'll write it down ...

I don't know if it is a bug though ... but its really annoying.

For a guy like, me - who has some programming experience - the issue for the following problem is prolly, that you're using to less threads or no threads at all.

My task manager reports 8 running threads on mIRC ( connected to 5 servers, 40 channels, 3 dcc-gets).

some examples:
If i load a huge logfile (1+ megs) into a custom window, press ctrl+f ... and try to search for something rare, my mirc hangs (cpu usage 100%, app isnt possilble to receive any user-input ... ) until it finds a match or the logfile ends.
If the file is REALL huge ... i'll get disconnected from servers (ping timeout) and all runing dcc-gets/sends are stoppin (prolly timeout too).

If i echo a LOT of stuff endlessy to a window, the same happens.
that means if somebody floods me on a dcc chat, and i havent any flood protection enabled (but an "on text"script, for a nicer display), my mIRC hangs and is getting disconnected.

And yes, i am using mIRC 6.03 (Windows 2000 Pro / Athlon 1,2G, D-link eithernet adapter ... dsl ).

If something is unclear, please ask ... cuz my English isnt that good, and i make mistakes sometimes

Loading a file that big into a custom window is ASKING for trouble. You might look into /help /filter or even /help $read. As for the flooding problem, you might think about using one of the many fine flood protection scripts available (or write your own).

I know what to to, if i dont want to be flooded. And of course i know that it isnt quite good to load a big file into a custom mIRC window.

Loading of the file isnt really my problem, cuz its really fast.
But opening a new thread for "searching for text in a window" would be nice.

This issue isn't just a problem of custom windows.
If i search for something on a really full and lively channel, it will also lock mIRC until the search function found something.

Applying threats to CPU intensive functions is always better, cuz it wouldn't block the whole application while the function is running.

I think one of the reasons why mIRC doesn't have more threads... say one for each channel or whatever, is because of the concurrency issues involved for mIRC scripts.

Might be True.

If i think about it, applying an own thread to the "incoming / outgoing"-messages buffer would be nice.

If i think more about it, the buffer could already be in an own thread, but cannot be processed cuz the thread responsible for processing the buffers is in use (by scripts, or by the search function in this case).

I know workin with threads isnt that easy.

If i think more about the "seach in windows issue" i think just putting a command to "pause the search, and process windows messages" like "Applicaion.ProcessMessages;" in Delphi (i don't know C++ ) in the responsible function would be enough.

lol why not think about not sitting in 40 channels that u couldnt possibly chat in all of them if ur life depended on it?? ...... lol either that or ur gonna need a 3.0 ghtz processor just to run a chat program

Sorry pal, but .. i don't get your point.

Whats so bad about sitting in 40 channels?
I could sit in even more channels, if i want to ... its not like mIRC's cpu usage increases by 1% per channel or something.

i think it's not the point "why" you are in x channels, but how you can improve an already good program

it sounds good to swap each search and other actions, that possibly could have a longer execute duration in particular threads.

Actually a friend of mine online and I experimented using threads on mIRC, and there's sort of a duct tape solution to making a "virtual thread." It pretty much involves a timer set to execute in a minimal amount of milliseconds (say 20) as it executes whatever command(s) specified. That way, mIRC does not hang while huge lists of information are being processed.

I suppose that would work, but it's just plain ugly :tongue:

I wrote a semi-advanced chatclient of my own once, not for IRC but for Battle.net and it had to option to run a certain alias in a seperate thread.

Adding that feature was actually quite simple, and made the aliases a lot more powerful. Of course this was partly because the rest of the program was already multithreaded

The scripting language didn't have as many features as mIRC, but I'd like to think I did the right thing with the multithreading. Before I added timers I would actually just run an alias with an infinite loop and a sleep statement..