Zugg Software :: View topic - [2.21] Incorrect context (or symbol lookup) in event handlers (found in 2.18)

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Per Zugg in one of the infamous scoping threads:

Posted: Wed Feb 27, 2008 6:16 am

Confirmed.

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Further info:

I attempted several workarounds for this problem (which I will dutifully remove when the basic mechanism is working). In the process, I discovered additional anomalies.

Procedure

Same as in the original post, except that I have altered the body of the onLoad handler to the following:

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Thread title updated to reflect that this appears to be more than just an incorrect context - there are some weird symbol-lookup behaviors (e.g. onLoadVar2 vs onLoadVar3 in the previous post).

Posted: Sat Mar 01, 2008 4:49 pm

Confirmed for all except number 4. Remember in a blank session, there is no value for %char. I tried it in a name session, and assigned a name for the session character and got a value. Here's my output.

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Duh. *slaps forehead*

Thanks, Tech. I needed that.

Posted: Mon Mar 03, 2008 5:35 pm

I have added this thread to the bug list.

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

I have developed a much cleaner workaround for this bug, which I will use until it is fixed.

I have a single onLoad handler in my package. It does nothing except '#say onLoadWorkaround'. Then I have triggers in various places that match 'onLoadWorkaround, and do the stuff that I would otherwise have used onLoad handlers for. Since the context for the triggers is correct, this works like a charm. It also gives me a reminder, every time I load the session, that I still have the workaround in place. Smile

A silent version of the same workaround can be created using #fire rather than #say. I will likely use this for my onPrompt handlers in the meantime.

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Oddly, it appears that MXP triggers may suffer from this problem, too. I am working on a test case, in the hopes that this might make it into the release this week.

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Still present in 2.20. Title updated.

Posted: Mon Mar 17, 2008 5:40 pm

Yes, this is still on the bug list and was not fixed in 2.20, sorry. Just didn't have time to fix everything.

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

No worries - it didn't sound related to the fixes for 2.20. Just keeping the buglist current. Smile

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

From the 2.21 Version History:

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

I think it may be a general event context problem, though. I have trouble raising events in certain ways from one module to another. I haven't been able to pare it down to a small, reproducible example that I could post.

Basically, I have buttons that I want to update on a certain event. There's an alias that toggles a setting and then raises the event. The event handler in the GUI package tries to change the color and/or text of a button, but I get an exception about not having permission or some such thing. If I am able to make it happen with a test case, I'll be sure to post it up here.

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

True. I don't think this is confined to onLoad handlers, though the fact that I get different results from '#raise onLoad' on the command-line and the event thrown by actually loading the package is problematic.

I'll put together a test case that uses only user-defined events, too. Might help to track this down.

Posted: Sat Mar 29, 2008 5:48 pm

The fix in 2.21 will only occur when OnLoad is fired internally from CMUD when a module is loaded. Using #RAISE OnLoad will not change the context.

I think it would help if you could put together a simpler test case that I can use for this. All I did in 2.21 was change the context of the OnLoad event called when a module was loaded to the current MUD window's context for Global or Published modules.

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Ok...putting aside any other events (since you haven't addressed them yet), here is a procedure to demonstrate the problem with onLoad. This is actually longer than the procedure in the OP, but it shows the two basic issues.

NOTE: I was mistaken, before. The failure mode in 2.21 is different than it was in 2.20. Confused

Start CMUD
Create a new session 'LoadTest' and load it in offline mode
Type the following at the command line:

Code:

#var winVar v1
Press Ctrl-G to open the Package Editor (PE)
Choose File->New Package. Name the package Handler
In the Handler package, create a new onLoad Event, with the following script:

Code:

#say onLoad - %window - @winVar
#var handlerVar v2
Quit CMUD
Start CMUD
Load the LoadTest Session in offline mode
In the main window, you will see absolutely nothing. It appears that the onLoad Handler did not fire at all. (In 2.20, the handler would fire, but appeared to have the wrong context - see the original post)
Press Ctrl-G to open the PE
Select the Handler module (in the Handler package) and switch it from Global to Local only.
Quit CMUD
Start CMUD
Open the LoadTest session in offline mode.
This time, you will see in the main window:

Code:

onLoad - LoadTest -

Note that the handler fires (!?!), and it knows the window name, but cannot see the winVar variable inside that window.
Press Ctrl-G to open the PE. You will see that the handlerVar variable was created inside the Handler module, not the window.

To be clear, my expectations are:

Every event handler is executed with a window as its context. Because it executes in the context of that window, it should be able to access settings in the window, and new settings should be created in the window by default. For the onLoad handler, it would be the window that is 'seeing' the package load (the main session window in this case). For user-defined events, it would be whatever window is executing the script that #RAISEs the event, etc.
An onLoad handler in package A/module A1 would be invoked for a window in package B if module A1 is Global or External, but not if it is Local.

If those expectations are wrong, please let me know. The current behavior (as shown above) appears to be at odds with both.

The failure is different than in 2.20, in that the handler will not fire at all unless the module containing it is marked Local - so, oddly, it looks like the change for onLoad with Global/External modules just made the event not fire. However, the issues with variables (can't see window variables, and new vars are not created in the window) are the same when it DOES fire.

I suspect that the variable problem is also present for other events as well, which is the bug that I was originally reporting in this thread (I just happened to use the onLoad event to do it). I will try to come up with a shorter procedure to demonstrate it using a user-defined event, so that there is not so much quitting and restarting of CMUD.

Posted: Tue Apr 01, 2008 6:28 pm

I was able to reproduce all of your issues with your excellent procedure. I think I agree with you about how this *should* work, and it does appear that the change I made in 2.21 made it worse (I think the change in context is preventing the IsInScope from returning true, so the event doesn't fire).

Anyway, I've got your procedure on the bug list in more detail now, so I should be able to work on this and get it working better.

Posted: Thu Apr 03, 2008 8:08 pm

OK, I have fixed this for v2.22, but not quite how you wanted.

In v2.22, your first example (where Handler is set as Global) works as you expect. It displays:

onLoad - LoadTest - v1

and it properly creates the @handlerVar in the current Window (LoadTest) in the same place that the @winVar is. So I think this is what you wanted.

However, I did *not* change the behavior when Handler is set to Local. When the Handler module is Local, it still gets "loaded" when the session is loaded. So, the onLoad event within the Handler module should still be executed. After all, the module just got "loaded" into the session, and regardless of whether it is Local or Global or External it should still call it's onLoad event to allow the module to initialize itself.

But in the case where Handler is local, the onLoad event does not get executed within any window context. Since Handler is local, it can't see anything outside of it's own package, which means it cannot see or access the window. So in this case, it displays:

onLoad - LoadTest -

as before. The %window object is global and still indicates which window currently has focus. But it cannot access the @winVar within the window, as expected. And the @handlerVar still gets created within the Handler module, because that is the context the onLoad event is being executed in for Local modules.

I think this is actually exactly what you would want as a package developer. It allows you to create a Local module within your package, and use the onLoad event to initialize variables within your local module. You can also create a Global module in your package, and the onLoad event within this module will create instance variables within the current window when it is loaded.

Along with the first change, I have done this fix so that #RAISE will properly use the window running the script as the context for the event. But if you manually tried to #RAISE onLoad, then the onLoad event within the Local Module of your package will not get called (because the window using #RAISE cannot see that module). The OnLoad event within a Local Module only gets executed when a session gets loaded by CMUD itself.

Let me know if you think this should still work differently.