Is there a way to have a .p automatically run an internal procedure, much like a destructor, when it is deleted, e.g. after invocation of an internal procedure in a SINGLE-RUN started .p?
Using CREATE WIDGET-POOL will already help in removing any lingering handle based objects (provided they were created in that widget-pool).
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...
isn't that what a final end block is for ?
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!
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?
Jeff Ledbetter Product Architect | Roundtable Software
No, only when you APPLY "CLOSE" to the procedure the event gets fired, not when (explicitly or implicitly) deleting the procedure.
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.
Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice http://www.cintegrity.com
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...