|
Joined: Jan 2003
Posts: 52
Babel fish
|
OP
Babel fish
Joined: Jan 2003
Posts: 52 |
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?
Last edited by lordares; 03/09/03 08:18 PM.
|
|
|
|
Joined: Dec 2002
Posts: 2,809
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 2,809 |
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.
|
|
|
|
Joined: Jan 2003
Posts: 52
Babel fish
|
OP
Babel fish
Joined: Jan 2003
Posts: 52 |
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.
Last edited by lordares; 04/09/03 03:54 AM.
|
|
|
|
Joined: Dec 2002
Posts: 1,527
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 1,527 |
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
D3m0nnet.com
|
|
|
|
Joined: Feb 2003
Posts: 2,812
Hoopy frood
|
Hoopy frood
Joined: Feb 2003
Posts: 2,812 |
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
Well. At least I won lunch. Good philosophy, see good in bad, I like!
|
|
|
|
Joined: Jan 2003
Posts: 52
Babel fish
|
OP
Babel fish
Joined: Jan 2003
Posts: 52 |
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.
|
|
|
|
Joined: Mar 2003
Posts: 1,271
Hoopy frood
|
Hoopy frood
Joined: Mar 2003
Posts: 1,271 |
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.
DALnet #Helpdesk I hear and I forget. I see and I remember. I do and I understand. -Confucius
|
|
|
|
Joined: Jan 2003
Posts: 52
Babel fish
|
OP
Babel fish
Joined: Jan 2003
Posts: 52 |
...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.
|
|
|
|
Joined: Jun 2003
Posts: 17
Pikka bird
|
Pikka bird
Joined: Jun 2003
Posts: 17 |
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?
|
|
|
|
Joined: Aug 2003
Posts: 1,831
Hoopy frood
|
Hoopy frood
Joined: Aug 2003
Posts: 1,831 |
45.Added identifier warning option to editor dialog options menu,
[color:red]halts script if identifier doesn't exist.[/color] It does say it wil halt the script if the identifier doesn't exist, so why are you surprised that it does?  [edit] Also, perhaps the No Such Identifier warning should include a line and filename? Agreed that would definately be useful.  [/edit]
Last edited by Iori; 05/09/03 08:08 PM.
|
|
|
|
Joined: Dec 2002
Posts: 14
Pikka bird
|
Pikka bird
Joined: Dec 2002
Posts: 14 |
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.
|
|
|
|
Joined: Jan 2003
Posts: 52
Babel fish
|
OP
Babel fish
Joined: Jan 2003
Posts: 52 |
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.
|
|
|
|
Joined: Aug 2003
Posts: 1,831
Hoopy frood
|
Hoopy frood
Joined: Aug 2003
Posts: 1,831 |
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.
|
|
|
|
Joined: Jun 2003
Posts: 17
Pikka bird
|
Pikka bird
Joined: Jun 2003
Posts: 17 |
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.
|
|
|
|
|