How would u capture the events in a custom @window _AS SOON_ as it text is sent to it automatically from a script or wherever? for example, you use 'on text' for chanmessages.
Is there an 'on text' style command, but for @windows?

Also, how do u do something with raw notices and privmsgs before mirc catches them? ie. before having to use 'on text' as some forms of privmsg don't get sent to the query window for that event to be triggered.

Btw, im asking for v6.0 commands not v6.12

on *:INPUT:@window:{ dostuff }

Triggers when someone types somethng and presses enter in the edit box of @window.

If you're talking about /echos and /alines then you would have to make your own /echo etc. aliases, or use an ugly timer.

I want to capture the text which will be automatically sent to a @window, so there won't be anything typed in an editbox.

For example, if i made a script to send 'hello' or ''bye' to a window at random intervals, the script would be sending it - no editbox required. I would then want to know how to trigger a command everytime something is sent. eg. when the word 'hello' gets sent to the window, it plays music hello.mp3 and when the word 'bye' is found in the window line, play bye.mp3

If i wanted to play music on certain words, I cannot set the music commands before the text gets to the window as i won't be knowing, nor controling the text that gets sent to the window.

you can't... that's the problem ;-]

script generated text cannot be catched by any event

[edit]
Sorry, posted that code without testing it before hand.

Another solution, which may be a little laggy, is to run a timer to check the window every X seconds for new text.

mIRC itself handles the change of a window by either beeps and/or tab colouring. ie. on a channel event, the normal colour change is to green, and for text is to red.
Would be nice to have an 'on event' or 'on change' code as it appears there isn't anything to catch this, which is annoying.

And the timer thing isn't very good as it will leave a large delay if an event comes in as soon as the timer has checked something, as it would have to wait nearly a second later before its picked up. In which time, more than one line could have been sent, meaning you would have more scripting needed to count the lines between checks etc.

Well not if you specify an 1ms delay, but I agree a timer wouldn't be even close to a good solution.