Forums Feature Suggestions non evaluating strings

I would like to be able to add non evaluating strings in some events
>> (%text == hi)
drawtext @window 1 verdana 12 10 10 %text $+ |
would look like
hi
if you could add a character >> like a ` or something to the front of it and add a switch(-asodifn, etc.) to recognise that so it would look like this
hi|

Use $eval(%text,0) or $(%text,0)

Why not use $chr(124) or $eval(|) ?

because thats a hassle lol

Khaled should use that same reply to justify why he shouldn't implement this feature, then.

You have two working examples, and many more that are just as simple to implement. They really are as simple as it gets. There's simply no reason for another, no matter how much less of a "hassle" it will be for you. To turn "`" into a special character would mean breaking hundreds of existing scripts that use it-- what's the point? So that foshizzle won't be "hassled lol"?

i didnt say it had to be ` or whatever

but lol idc

just a thought

you're quite the person to argue everything negatively. Why not use some common sense and type what people would actually learn from? Instead, I'm going to say: I think that mIRC should also use the \ method, and recognize that if it's only one, then it isn't special, but if it comes before a character, then it shouldn't evaluate the next character, therefore knocking everything out, because not everything has a $!identifier method.

Speaking of which, if you want to create non-evaluating scripts, just use a ! in between the $ and the identifier. I'm not sure if this works for all of them but I'm sure it is a way to not evaluate strings.

Using \ would have been a *decent* idea if it was decided on at the birth of the language, rather than 9-10 years down the road...

However, there are hundreds if not thousands of scripts that have \this or \that in them, specifically those that reference any kind of path whatsoever, so it would simply not work.

Even if it did come with the language, there are huge issues with basic use of "\" since it is after all a character used in the Windows filesystem.. would you really want to escape every \ in every path you reference? That would be a huge pain.

Call me negative, fine, but I believe I'm giving realistic insight to the problems that can be faced due to rash decisions about changes that can affect a large number of users. It's important not to only blindly look at the positive aspects, but the negative ones as well. I give enough credit to all users posting that there is *some* positive benefit to the feature being suggested, so why focus on that? The potential problems are far more important.

Yes, $!identifier will escape it, so will $(anycharacter), which is mIRC's current method of doing it.. The point is, I see no reason why this should change-- it works and works well.

What is negative about pointing out that if there are *easy* and *simple* methods of doing what was asked, that there is no reason to make some change that will potentially break a LOT of scripts?