SINGLE-RUN procedure - Destructor like functionality?

Good morning,

isn't that what a final end block is for ?

FINALLY:

your code

END.

Then I would need a FINALLY block in every internal procedure of the .p, which defeats the purpose of having a single cleanup routine, much like a destructor.

Putting a finally block in the main block of the .p gets executed before running the internal procedure, so that's no option either.

I know there is a good reason for it but just out of curiosity. Why use .p and not just a class?

Haha, I knew that question would come ;-)

We're dealing with HLC calls to C code and that uses shared variables as communication means between ABL and C.

Shared variables can't be used in OOABL...

I'm totally confused about what the question is.  SINGLE-RUN procedures work like this:

In single-run mode, the external procedure is instantiated only when an internal procedure or user-defined function that it defines is invoked remotely. The single-run procedure is deleted when the internal procedure or user-defined function completes.

So it does get deleted.  So what you want is to run some specified internal procedure before it gets deleted?  And given that you don't want to code a FINALLY block into each .p, it sounds like you want it to be some shared internal procedure or a method (i.e., in some other persistent procedure or class?).  Interesting.  No.  There is no way to do that!

Hi Laura,

I'm looking for the equivalent of a destructor/finalizer for a persistent/single-run procedure, i.e. something that gets called right before the procedure gets deleted, which gives the chance to clean up things that don't automatically get cleaned up by the .p going out of scope.

A finally block would have to go in every internal procedure of the .p; i'm looking for something scoped to the .p, not to every internal procedure.

Thanks for confirming no such thing exists.

Ah.  Gotcha.  Nope.  Sorry.

Does the ON 'CLOSE' event get fired for the procedure?

No, only when you APPLY "CLOSE" to the procedure the event gets fired, not when (explicitly or implicitly) deleting the procedure.

That might be something PSC (Laura) can help with, apply that 'CLOSE' event under the hood whenever a DELETE PROCEDURE is executed... still a somehow transparent implementation of a destructor ;)

As Marian implied, ON CLOSE only fires from an APPLY statement.  The AVM never fires this event itself.  Yes, this functionality could be provided in different ways.

But I'm not sure of the benefit of discussing all the ways we could do it at this point.  This would be a new feature.  If we ever do it, we this can be discussed at that time.

As Marian implied, ON CLOSE only fires from an APPLY statement.  The AVM never fires this event itself.  Yes, this functionality could be provided in different ways.

But I'm not sure of the benefit of discussing all the ways we could do it at this point.  This would be a new feature.  If we ever do it, we this can be discussed at that time.

As Marian implied, ON CLOSE only fires from an APPLY statement.  The AVM never fires this event itself.  Yes, this functionality could be provided in different ways.

But I'm not sure of the benefit of discussing all the ways we could do it at this point.  This would be a new feature.  If we ever do it, we this can be discussed at that time.

To me, the obvious right answer for the requirement is to use a class instead of a .p, so let's return to this issue of HLC and shared variables.  The idea of anything outside of ABL supporting shared variables seems odd.  What is the possibility of rewriting the C side of this to accept parameters?  That sounds like a much cleaner solution in many ways.

The obvious right answer just can't be applied when using HLC, since shared variables and buffers are the way to return data from C to ABL...

At one point creating an OOABL single-run facility modeled after the procedural single-run facility was discussed within development.  It seems to me that if we supported such a facility, the behavior requested in this post would be available via the class destructor.  

We have used your suggested approach with success: A companion OO object that keeps the state of the .p could also be an option, which gets its destructor called when the reference the .p has to it goes out of scope...

It's not as clean as having a language construct build in off course but it does work reliably.