FWD » Core Development » Base Language

How I see this working: we have a SelfManager class which manages a stack of "self" handles. Each event responsible of creating a new SELF handle must call SelfManager.pushSelf(<handle>) before calling the trigger/procedure/etc and will call SelfManager.popSelf() after calling the trigger/procedure/etc. KW_SELF will be converted to SelfManager.self() and will act as a real handle. Any i.e. ch = self:private-data calls will be converted to:

ch.assign(handle.unwrap(SelfManager.self()).getPrivateData());

I like it.

I'm leaving a conversion to run over night, hopefully all SELF-handle usage will convert nicely.

Conversion regression testing has passed - compilation was OK, all changes are expected.

Code Feedback:

1. refName is a dead variable and can be removed from methods_attributes.rules.

2. How do we emit the frame/widget getter for static widget (not handles) attribute/method dereferencing? It would be useful to explain this in a comment in methods_attributes.rules.

Otherwise, it looks good.

Am I correct in understanding that all that remains on the runtime side is to review all event types (other than UI triggers which are already implemented) and implement the handle push/pop properly. That should not take long at all, as far as I can guess.

Be ready to merge up. We will go into testing later today.

The code looks good.

      This rule-set covers only the cases when an attribute/method is accessed using a handle ref
      (returned by a method, a variable, system handle, etc). All cases of widget attributes
      and methods accessed using the widget (with or without a frame qualifier) are managed by
      the frame-related rules, as annotations/frame_scoping, covert/ui_statements and 
      convert/frame_generator.

I think it might be more correct to say that the rule-set only handles the resource reference for handle types. In the cases where static frame/widget/buffer resources are accessed using the COLON operator, the resource reference is emitted elsewhere but the attribute or method part is still emitted by methods_attributes.rules, right?

This is the latest version merged up to bzr 10188. It will go into testing next.

Passed conversion testing. Checked into bzr as 10189.

The change looks fine. This is being conversion tested now.

Committed to bzr revision 10194, passed runtime regression testing.

About the runtime implementation of SELF handles: I don't want to do this in a separate task; instead, each case which can generate a new SELF handle should be implemented when that feature is implemented (and the implementation is as simple as adding push/pop calls using SelfManager APIs).

Transcript from the docs:

• You can reference the SELF handle only within a user-interface trigger or the
event procedure for an ActiveX control or asynchronous remote request.
• In user-interface triggers, SELF is not automatically the widget that has input
focus. To give input focus to the widget referenced by SELF, you must apply the
ENTRY event to SELF within the trigger block. Note that you must do this for fill-in
widgets whose AUTO-ZAP attribute you want to set, as in this fragment
• In the event procedure of an asynchronous remote request or in the context of a
procedure called directly or indirectly by this event procedure, SELF returns the
associated asynchronous request handle.
• In the event procedure of an ActiveX control, SELF returns the control-frame
handle and the COM-SELF system handle returns the control-frame
COM-HANDLE value.
• If referenced within a READ-RESPONSE event procedure, then SELF is the
socket handle associated with the connection that received the message. If
referenced within the CONNECT event procedure, then SELF is the server socket
handle.

We should add notes to each task associated with each above case and close #2015 and #2013 (note that UI triggers are implemented properly).

NullWidget usage should be removed and SELF handle (for widgets) tested carefully - see notes 21/22 in #1612.

What is left to do on this task? I think your recent work with async events/sockets probably filled most of the gaps. We aren't going to do anything with Active-X controls in this task, so I wonder what is actually open here. Perhaps just the NullWidget stuff is open?

Perhaps just the NullWidget stuff is open?

Yes, only the NullWidget usage remains to be removed.

Code Review 0120a

I am fine with the changes. Commit and distribute them when they pass testing.