Can you use Event-Procedure inside an ABL Class?

You don't; you have the object start a persistent procedure and have the event procedure in that procedure call back into the object.

run myproc.p persistent ( this-object ).

/* myproc.p */

define input parameter ipMyObject as my.object.class no-undo.

procedure callBackProcedure:

  ipMyObject:HandleCallBack ( ).

end procedure /* callBacklProcedure */.

I figured that much. I'm thinking if there is a direct support in GUI for .NET.

Not yet.

"Nothing wrong with" = "works just fine", but that doesn't mean it isn't annoying to have to break paradigm.

I agree.

But for my understanding "direct support in GUI for .NET" means everything usable in the Progress 10.2A GUI client. That's different from asking for direct support in OO-ABL.

We won't get rid that soon of the procedural legacy in the ABL. I expect it to remain there for decades.,

So much for my dreams ...

Dreams or nightmares?

Dreams of OO replaced by nightmares of being stuck with odd bits of non-conforming, unnecessary procedural legacy.

Or you could be wicked and think of the confusion that a future maintainer of the code when he sees a .p being run by a .cls so that the .p can subscribe to an event just to call a method in the class that called the .p. (!)

You can imagine the question ...

WTF ? Why didn't they just use the THIS-OBJECT:SUBSCRIBE(MyMethod,"SomeEvent"). ??

- Assuming that in 12.3B you can subscribe methods to events

Exactly why I would document any such use with CMA comments saying "What I want to be doing here is ... , but that isn't supported in this version of ABL, so I am doing .... instead".

Aw, crap. You just have to take the fun out of everything ...

Heh. Just grepped the source code, came out with some crackers:

/* FIXME: date(TODAY) is used because of a bug in progress 10.1B00 */



DEF FRAME DocFrame 

    HEADER "Date:" AT 1 DATE(TODAY) FORMAT "99/99/9999" 

and

/* DO WHILE LOOP IS BECAUSE OF BUG IN XML OBJECT - IT SOMETIMES PUTS CRAP AT THE END OF THE TEXT */



 DO WHILE lv_cXML GT "":U AND SUBSTR(lv_cXML,LENGTH(lv_cXML),1) NE ">":u:

  ASSIGN SUBSTR(lv_cXML,LENGTH(lv_cXML),1) = "":U.

 END.

and

          lv_iEntries  = NUM-ENTRIES(lv_cAddress).

         

         CASE lv_iEntries: /* note: CASE NUM-ENTRIES(Variable) is broken in 10.1A. Fix this when Progress is fixed :) */

perhaps I should fix these now

That is the problem, of course ... you can comment it and that gives one a clue when revisiting that code, but how does one proactively fix it.  Code that one can put into common base classes inherited by large groups of subclass is one obvious way to highlight such things, but obviously isn't going to work for the current issue.  The only way I can think of to stay systematically current would be to get to a point where one's entire system was model to code and one simply updated the transform rules as new capabilities came along.

THIS-OBJECT:SUBSCRIBE(MyMethod,"SomeEvent"). ??

Hmmm. Why wait for 12.3B?

What is desireable is something PSC could implement in hours, or a few days, if they were so inclined.

RUN 

  {     extern-proc-name 

     |  VALUE ( extern-expression ) 

     |  path-name<>> 

  } 

  [ PERSISTENT [ SET proc-handle ] ] 

  [ ON [ SERVER ] { server-handle | session-handle } 

       [ TRANSACTION DISTINCT ] 

       [ ASYNCHRONOUS  

            [ SET async-request-handle ] 

            [ EVENT-HANDLER { object-which-implements-IAsynchCallback-interface | event-internal-procedure [ IN procedure-context ] } ] 

       ] 

Similar tasks in diferent contexts

server-socket:set-connection-handler ( { event-procedure [, event-context ] | object-which-implements-IServerSocketConnect-interface } )

socket:set-read-response-handler (  { event-procedure [, event-context ] | object-which-implements-ISocketReadResponse-interface }

sax-reader:handler ( procedure-handle | object-which-implements-the-ISaxReaderCallback-interface )

and so on.

Of course, what would really be cool is if in

create server-socket myServer, myServer could either be a handle or an object which implmented a predefined ISocketServer interface.

likewise,

create sax-reader r where r is a handle or an object which implements the ISaxReader interface.

There are any number of places in the language where I think this type of thing could be done without a lot of extra work.

I think they really do need to implement a full support of Delegates. Callbacks and Events are just flavors of Delegates in .NET world.

Without disagreeing with you, allow me to observe that to my mind,

"implement a full support of Delegates" == BIG JOB!

Maybe, maybe not, but that's what it sounds like.

One the other hand, add support for ISaxReaderCallBack == little job, + add support for IAsynchCallBack == little job, + add support for ISocketReadResponse == little job.

Use lessons learned from little jobs to tackle big job.

Don't underestimate the value of small steps. There are a dozen or so places in ABL proper that use the callback mechanism; it would improve things greatly if  we could use objects instead of persistent-procedures for the call backs.

No doubt delegates will be coming, but they are not scheduled for 10.2B, which likely means means not for another year at least.

What I do locally to support delegation is define an interface, create a variable for that interface, create a method which accepts an object implementing the interface, create an object which implements the methods of the interface. assign the object to variable using the method. It has its limitations, but provides some flexibility.

10.2B language enhancements. Is this what is being asked for (Stronly Typed Events).

Language (ABL)

• Abstract Classes, which are classes that cannot be instantiated, can be defined in 10.2B so as to provide a common definition of a base class that can be shared by multiple derived classes. A limitation has been removed where previously an ABL class could not inherit from a .NET abstract class if it contained abstract properties.
• Strongly Typed Events may be defined, published, and subscribed to in 10.2B.  In addition to making it possible to define native ABL events, this allows an ABL application to implement a .NET interface that defines an event or inherit from a .NET class that defines an abstract event.
  
• Dynamic Object Invocation provides the ability for an ABL application to invoke a method whose name is not known until runtime. Two facilities have been added to the ABL to provide this capability. In one facility the parameters for the dynamically invoked methods are specified at compile time while in the other the parameters are specified at runtime.
• Temp-Table and ProDataSet Improvements make it more efficient to code certain versions of the optimistic-locking phase of dataset updating.
• Codepage Conversion of Text Segments in Memory-Mapped Procedure Libraries provides functionality where if the codepage of a memory-mapped text segment does not match cpinternal, the text segment will be codepage-converted in local memory and loaded into the r-code execution buffer.
• Generics provide the ability to instantiate and access a .NET Generic class form the ABL.
• Support for Read/Write of JSON to/from a ProDataSet provides the ability to serialize a ProDataSet, temp-table, or temp-table buffer object in JSON (JavaScript Object Notation) format, and to parse JSON and store it in a ProDataSet, temp-table, or temp-table buffer object.
• ABL Development is seeking customers who will carry out performance analysis for their applications on 10.2B and provide data for study.

As regards delefgation, no. Strongly typed events are a precursor for .net delegation, necessary but not sufficient.

As regards HBOs*, I don't know, I'd need to see more details, but I suspect not. While there is, no doubt, an architecture which requires Strongly Typed Events in order to provide access to HBO eventing, there are other architecture which merely require Dynamic Object Invocation, and still others which require neither. The problem isn't primarily in the ooabl, it's in the HBOs.

*HBO = handle based object. 

EVENT-PROCEDURE is more like plain delegate (callback procedure, named address).