Forums Bug Reports mIRC Freezes on long Loops

Well I don't if this is a bug or not, but whenever you make a Very long loop (like 100K comparisons) then mIRC Freezes.
This is very annoying because mIRC isn't responding to anything, and all the dialogs and windows freeze while it's running the loop.
But after a few seconds (like 20 or so, depending on the size of the loop) everything goes back to normal.
Anyway, when the loop takes more then 40 seconds or so you are also disconnected from most of the servers you're connected on because mIRC didn't respond to anything while the loop was running.
So, would it be possible to make mIRC use its resources more efficiently so it can run one loop and still respond to other events ?
I agree that same events must process one after the other so the order remains.
But I'm trying to do a simple thing like loading a dialog and mIRC freezes until the dialog is loaded....

everyone who's ever run a loop or screwed up a while loop or an if loop knows that mirc freezes when looping.

Download a DLL called "whilefix.dll" from www.mircscripts.org and you won't ever freeze mirc during a loop again.

An example of using it in a script:

i think i'm experiencing the same
i've experienced numerous total freeze of my mirc today, on both of my comps, one having litteraly no script...
and this is the 5th time, i'm forced to kill the process everytime, it gets stuck and doesnt use any cpu, i tried killing particular threads, but no effect

Paticular threads? mIRC is single threaded so uh what are you talking about?

If your loops are freezing mirc, optimize your code.
I have a lot of real-time adds running in my mirc and i don't notice that.

btw it is running in a pIII 450Mhz!

P3 450's Unite WOOT yea I dont have problems with mirc locking up via loops

??

oops, ignore my previous message, i posted in the wrong thread, i'll blame that on going to bed too late:)

Well, belive me I got down to minimum, but try doing a simple filter with an alias on a window that has 12,000 line, and you'll see that there's nothing muchy you can aobut it...
I use a simple sort code to sort file sizes (Mb, Kb, etc..) and that takes about 20-30 secondes to process.

var %b = $calc($replace($remove($gettok($2,3,9),$chr(32),b,$chr(160)),k,* 1024,m,* (1024 ^ 2),g,* (1024 ^ 3)))
if (n isin %a) return 1
if (%b !isnum) return 1
var %a = $calc($replace($remove($gettok($1,3,9),$chr(32),b,$chr(160)),k,* 1024,m,* (1024 ^ 2),g,* (1024 ^ 3)))
if (n isin %a) return -1
if (%a !isnum) return -1
return $iif(%b > %a,-1,$iif(%a > %b,1,0))

Pretty simple code, yet necessary ... I don't think I can reduce this much...

I just want to point out that there's a problam here, and I would like to ask if it may be fixed in the next versions ?

well that code is fast, maybe your problem is in another place... 20-30 is a lot to do what you say m8.

what is your cpu speed?

Why don't you add all your data to the hidden window in bytes, then use /filter on the specified column, without repeatedly calling an alias.

If you are worried about getting the sizes back in their original state, like kb, mb, whatever, then simply add an ID to your data. Like for each line, add a flag, that will state what the original file size format was, but add the size in bytes. If you have to deal with those sizes later, you can format them easily by retrieving the value of this ID, and using $bytes to format.

I'm sure that adding such ID won't hog nearly as much resources, than repeatedly calling an alias to sort.

Greets

hehe, well we are starting to get a bit off topic here...
That was just a sample for something that might take a long time if there's a lot of data to process, but that's not the only thing.

Anyway, if we are talking about it already, so here's some more info:
The text itself is in a dialog list, and the file size, as you've probably figured already, isn't the only thing in the line, so I need to sort it so the whole line stays, but it sorts only by a part of the line.
And yes I do use /filter from a window, because it's much faster:

/filter -aco @Window-name Dialog ID Sort-by-size

so it's a tricky situation

Anyway, as I said it's just an example.
I have encountered this many times, and you can do a simple loop of 20,000 with an /aline command in it to see how a simple thing like that can take a while.
I usually test this by making a %ctime var before the loop, and $calc( $ctime - %ctime) after it.
Anyway, I think you get the point...

It's not a bug, just the way mirc has always worked. There have been interesting suggestions related to this, you might want to take a look.

your @window isnt a listbox is it, they are real slow to do filters on, nothing to do with the sorting, everything to do with the size of the data on each of the lines and the getting it in and outa the listbox I have found, i got one that just a alpha sort takes 20 to 30 seconds on. If it wasnt a listbox it takes less than a second.