Forums Feature Suggestions on 1:NewLine:*:{ do this. }

I would like to see mirc have an on NEWLINE event...
which would work for echo's etc.

also MODLINE (modified line) DELLINE (delline) etc would be good

This would be a simple add on to mirc for khaled... The code to add it is allready there... now just to add a signal

Can you explain in more detail when and under what circumstances such events should be triggered (use examples if you want)

I mean whenever a line is sent to a window...
Such as every time the status window is updated with whatever...
Every time a channel window recieves text, actions, echo's etc

every time ANY line is written on a window

Sounds like you're basically suggesting something like a combination of ON TEXT, ON ACTION, and ON NOTICE for channel windows? What about for pm/queries? If this was to be introduced, would it activate as well as a matching ON TEXT/ACTION/NOTICE event (similar to having 2 matching events in different scripts), or would it run overriding (or being overridden) by a previous event (as is the current case if 2 matching events in the same script)?

I admit, there have been times when it would've been nice to be able to use something like this, especially if the response is the same irrelevant as to the type of event, so I could write up code using the one event, rather than 3.

He's saying that whenever a line is written to any window (status/channel/query/chat/custom/etc) an on newline event should be triggered. Even when you just /echo lines I think.

I have to say I do not like this, it encourages bad programming techniques. Some scripted event or internal mIRC code (which can be disabled) is generating the output to the window. You should be changing, monitoring, or updating the source. If you do not know why, when, or how, maybe you should read more about the details of the mIRC language and the IRC protocols, or ask specific questions (in the Scripts & Popups forum)

Naquada

Well, I can see a use for it. I don't really know why you need to consider echos, but the ability to have a single event that covers all forms of messages so that you don't need multiple events that all do the same thing could be useful.

Heh, i almost suggested something like 'raw *:*:signal bleh' to cover incoming events before i realised mirc wont allow it However if you check out io.dll by Saturn you could use this to essentially do the same. Although i think its kinda of misusing it to trigger absolutely everything.

Of corse this doesnt cover anything script or user initiated, but its better than nothing as a solution to your suggestion.

I would personally prefer not to include this suggestion, however i can see a use for it if only to reduce code (for example, an antispam script would need just one event rather than half a dozen).

I have no objection however for a similar event that is limited only to internal new lines (like echo and aline).

And just for the sake of the discussion ON *:NEWLINE:MATCHTEXT:METHODS:{} where methods (or whatever you want to call it) definate the type(s) of newlines to trigger on.

Regardless of all this, my impression from the OP was that they mostly intend to use this with the /*line commands. In which case concider a workaround for now...

alias aline { signal whatever aline $1- }
alias dline { signal whatever dline $1- }
ON *:SIGNAL:whatever: { if (stuff) { $1- } else { halt } }

Actually what I was referring to was being able to use all text from a window...

Heres a couple of examples.

nHTMLn windows: You turn timers off, The result is not displayed

Dialogs: You would like to make a custom query window (with a dialog), You have to make custom aliases for everything you send, CTCP, NOTICE, PRIVMSG, MSG, RAW, etc. You then have to recieve everything so you make events for NOTICE, CTCP, CTCPREPLY, PRIVMSG.... etc... You still dont see anything if you use a command such as /timers off.

I wouldnt recommend this as a "recieved"/event scripting technique, More so... it would be to copy a window's contents when it arrives... It SHOULD be simple for Khaled to implement, and a great use to many users.

I think, that this feature will allow to create a new IRC client based on mIRC client very easely... Style it whatever you want etc.
But yes, if this could be done, I would find a use from it

I personally think it would expand mirc into the previously 'trialled dimention' - it allows users to do something that scripting cant normally do properly, which has been attempted many times.

ON 1:NEWLINE:<WindowName>:{
echo -a Theres a new line on $window
}

What can't "scripting" do "properly"? What do you define "properly" as? Properly is definitely not using a workaround event like on newline to capture text that was triggered from other sources (on text, action, raw).

You also get into consistency issues of "does /echo trigger an event"? and if it does, you wouldn't be able to use echo's (to the target window) in an on newline event, it would just recurse infinitely.

And if you're just trying to capture non /echo'd text, well then you can already do it with the proper events. If you can't, then you should make a feature suggestion for that specific missing event.. not all of them together. That's not "proper" scripting, in my opinion.

Just to go a little further.. incoming text into a window is rarely just a "line". It has extra important information that goes along with it (on text has $fulladdress, $nick, etc., on op has $opnick, ...) You can't just generalize this differing information into a "line"- they are distinct events and you handle them differently too.

How would you even use an event like this? How would you differentiate the "lines"? What, would you check that "sets mode: " is in $1- to tell if its a mode event? If that's what you were thinking, then this explains why this event would be a horrible idea.

You do you that he just just make a new trigger: on *:ECHO:*:{
All of the other items that make a new line are already in the engine, ex: on TEXT, on NOTICE, on ACTION, on MODE, etc.

Well there's also /aline, /iline, /play, /filter, /loadbuf, and probably one or two more I've forgotten.

on *:echo:* would be usefull for somethings, like status windows, program notices, mIRC internet events

I don't see it having any legitimate uses beyond whats already coded.

This could be useful for possible highlighting or logging. An example...

on *:NEWLINE:*:*:{
echo -a $1- :was just said $iif($chan,on $chan,by $nick)
}

This is just a simple example but this event could be very useful in many more ways than one.

However, your example would trigger itself over and over... at least until you got the Line Too Long error. Every echo the script made would trigger as being a "newline". This is where that event or an on ECHO event would be problematic. Obviously, you can avoid the problem by just not echoing/displaying anything to the "watched" window/channel. Even so, I really see little use because you'd be limited on what it would actually handle.

I'd rather just put the echos right into the scripts if needed.

This is so completely random and off topic, but...
It is a common misconception that people fear failure, in most cases it is infact an unconcious fear of success that is the most damaging.

Ok... I can understand the recursive loop problem, But still... Lets say for example... I have a emoticon window (Dont get on my back - its an example)... I might want to display the things like "* Retrieving #channel modes..." when loading mIRC Channel Central... Yes - I could work around this... by making a custom /channel alias... But theres many times this could be used.... such as internal mirc errors, eg... *Tokenize: not enough parameters...


Etc... anyhow, There could be a issue with the loop... but less than what there is in /while ;\

I understand what you're saying, but I still think it's better to just have events for such things rather than a "global" event that covers everything. Yes, you may be duplicating code, but you can use an alias and call it from every event and it lets you disable events that you don't want it to work with.

Having the on ERROR event work with mIRC errors rather than just server errors would be one nice addition.