Forums Bug Reports $event doesnt exist? ;)

6.1 with identifier warning enabled.

* No such identifier: $event

The line being called is:
$iif($event != TEXT,$active,$chan)

Also, perhaps the No Such Identifier warning should include a line and filename?

Umm, well is that inside an ON event? If so, can you paste enough code so that someone can actually test the code and try to reproduce it?

ON *:INPUT:*:{
.echo -a $iif($event != text,y,n)
}

That works perfectly for me.

hm, ok, well I figured it out, it's definitly a bug:

Here is an example of how to recreate it, although I'm not using this code myself, it will create the bug..

alias say {
eventecho $1-
.msg $active $1-
haltdef
}

ON *:TEXT:*:#:{
eventecho $1-
}

alias eventecho {
echo $color($iif($event != TEXT,own,normal)) -ti2 $iif($event != TEXT,$active,$chan) $iif($nick,$nick,$me) (eventecho: $+ $event $+ ) $1-
}

;The above alias will work for ON TEXT, ON INPUT, and a scripted /say to echo output dynamically depending on $event.

True, calling $event remotely from an alias might be bad style/scripting, it does work because of mIRC being single threaded.

If the identifier warning is Disabled, the above code will work, if the identifier warning is Enable, the above code will not work and will error saying $event does not exist.

A workaround would be to send $event to the alias of course, but the purpose of the post is to alert Khaled of the bug with his Identifier Warning feature.

id say its a bug in your scripting ... $event shouldnt be called outside of the event how can that be a bug when its not formulated correctly? maybe khaled wants it to return that error because mirc may be multithreaded someday? in that case u would have to learn to script it correctly

The purpose of $event is to be used within an Alias called from an Event. The idea is that a common Alias can share the same code for multiple Events, but with minor differences depending on the type of Event calling the Alias.

It's also useful in debugging purposes to track down an error and which Event is responsible for it.

- Raccoon

This isnt a 'how do I make this work' forum, it is a "Bug reports" forum.

If Khaled intends $event to not work how I am using it, then he should *fix* it so it shouldn't or, fix the bug in his new feature.

It is up to him to decide, this isn't open to discussion, an obvious work around would be to send the $event to the alias as a parameter, but a bug is a bug.

If Khaled intends $event to not work how I am using it, then he should *fix* it

That's the other way around -- you are using it the wrong way. Use it the right way.

...Did you read my posts?

"Here is an example of how to recreate it, although I'm not using this code myself, it will create the bug.."



It is most certainly a bug, if I can CALL $event the way I show, then it either needs to be disabled or the identifier warning needs to be fixed.

One of them is bugged, as I've said, it is up to Khaled to decide which one is the bug.

I copied your code into a blank script file and joined a channel. Then I joined the channel with a different running mIRC and said "Testing." With the first copy, containing your code verbatim, I got:

<dohcan2> Testing.
dohcan2 (eventecho:text) Testing.

This is with Identifier Warning enabled. The only time I get "* No such identifier: $event" is when I do /say from the command line, and this is expected behavior because it's never passing through an event. If I put "say $1-" in an on input event, I get (after having typed "hi" and pressed enter):

dohcan (eventecho:input) hi

Which, again, is expected. What exactly is the bug?

It does say it wil halt the script if the identifier doesn't exist, so why are you surprised that it does?

[edit]Agreed that would definately be useful.
[/edit]

confirming everything everyone else said. just adding that i use $event to detect if an alias was triggered by an actual event, or something manual by the user. in the case that the alias was triggered manually, i have it do some extra work.

The bug is $event should eval to $false or $null, which it DOES if the warning is disabled (for /say), but if enabled it just halts the script.

Well I think $null is what it should return in the circumstance. Perhaps it's interpretation, but to me, if something is NULL then it doesn't exist.

Everything returns $null if it doesn't exist, with the warning disabled. The point of the warning is to prevent you from using an identifier when it doesn't exist. However, I'm thinking this is just for debugging a script and that normal operation should be to use your scripts without that warning.

If you only run your own scripts, you could probably get away with leaving the warning enabled. But as you saw, you may have to use different approaches. I don't believe this is a bug.