Forums Bug Reports while loop freezes command prompt

As far as I can tell, the most likely cause is as follows. It's merely a theory, as most of it happens somewhere deep down in Windows:

• Your script calls /clipboard at first, which makes mIRC put an empty string on the clipboard. mIRC then owns the clipboard at the time that clip.exe is started.
• Clip.exe tries to put new contents on it. It therefore wants ownership of the clipboard. clip.exe queries mIRC about the change of ownership, to let mIRC do any cleanup if it wants to.
• However, mIRC doesn't respond to the query, because your script is keeping mIRC busy. Clip.exe waits a few seconds before it gives up on mIRC, and then grabs clipboard ownership anyway.

The querying and waiting happens at the Windows level*. The delay is five seconds on my system, perhaps it is fifteen on yours. In any case, this has nothing to do with clip.exe. In theory, mIRC could solve it by giving up ownership of the clipboard when putting an empty string on it.

*) To be exact, the query is a WM_DESTROYCLIPBOARD message, resulting from an EmptyClipboard() call.

EXACTLY! BINGO gj Sat!
To see the desired result of what the script in the first post *should* do...
Take out the /clipboard
-->
Log-Off windows then Log back in... clipboard is defaulted to $null
-->
Then open mIRC and do /ipconfig
from alias in 1st post with the /clipboard removed
-->
It outputs to the @win as desired...

So is it ok for mIRC to release an empty clipboard when /clipboard $null (as a bug fix)
or is there a reason mIRC would want to "keep control" of an empty clipboard?

As Sat suggested, I think is the case--which PhireCoder seems to have found to be true. I tried the alias, myself, and found that while it ran, my CPU never even spiked above 10%, and no other programs were frozen or delayed. Just mIRC and the command window. So it's not a question of the while loop eating too much CPU, but the clipboard not being released. It would seem to be the solution is for mIRC to release the clipboard (a shared system resource, which only one application can "own" at any given time) as soon as possible. Possibly a flag given to the command telling mIRC the script wants to release it right away?

Sortta off-topic (in the sense this isn't what the OP was reporting).. Why do it the way you have at all? For something like this, you could just use redirection ("@ipconfig > ipc-out.txt") to save the output to a file, then have mIRC read in the file, and echo it to your custom window.. better yet, you could also manipulate the output file any way you want, pass it through other filters, etc., before reading it into mIRC.

Cas

I have been able to reproduce the same delay here, however I haven't been able to find the cause yet.

mIRC registers itself as the owner of the clipboard whenever it reads or writes to it and then releases the clipboard so that it is available for modification by any other application, as per the Windows API documentation.

It may be that when clip.exe updates the clipboard, the clipboard tries to contact the previous owner, mIRC, using a Windows message, as a matter of protocol. Since mIRC is in the middle of a script loop it can't process incoming Windows messages, which results in the delay.

I can't see a way around this issue currently. That said, outputting the results to a text file instead of modifying the clipboard would probably be a better idea.