Hi Ben We do have globale procedures and includes which (try) to track all "activations"of components. There is an STD_OPER include at least which defines the INIT and CLEANUP operations which then calls LP_INIT/LP_CLEANUP (if defined) We do have SP_FRGF/SP_FRLF procedures to track "form get focus"/"form lose focus" We do have SP_ACCEPT/SP_QUIT/SP_EXIT to track ACPT/QUIT/EXEC-triggers Then there are some global procedures which are call indirect by this procedures. To get information about the old way of calling by RUN, I did wrote some "prolog"/"epilog" procedure wich could be called before and after the payload of an operation (incl. EXEC). The whole thing is very trick and every change in the "calling conventions" of UnifAce can break the flow of information. With this tools, I get always (I hope so) the "environment" of an instance of a component. BUT: Hello Uniface, what about some more information, accessibale by proccode at runtime? Regards Ingo

Inigo,  $proccontext("STACK") gives you the current path (including line numbers) from app exec trigger to the current line in code.  The OP wants the current path stored in memory in the DB connection so it doesn't need to be set before every write to the database.  What would possibly be good is some form of switch in the db connectors which set up context_info or something else from which db level triggers could read the call stack information. It's the fact that the logging is done within the database triggers which makes this tricky. Otherwise 'simply' changing all the write/delete triggers of the entity in the model and the component variations thereof to do the logging would work. However, this doesn't trap changes due to direct SQL or stored procedures... 

We do it before any database transaction, which does have the issues you've mentioned, however, where it does connect correctly (approx 90% of the time), we can then use call stack to get the entire path through the app to get to the point in the code.  For your point however, if all the forms are modal, does the operation Init and Cleanup work for you? You could have a global variable storing a list of components and take the last one off the list.  operation Init putitem $$contextlist,-1,$componentname($instancename) sql("set context_info '%%$itemnr(-1,$$contextlist)%%%'",) end operation Cleanup delitem $$contextlist,-1 sql("set context_info '%%$itemnr(-1,$$contextlist)%%%'",) end

usually if you work with modal forms, you do it by EXEC trigger. So you can place your "form gets focus" at the top of the exec-trigger and "form loses focus" at the very end (after the "edit" statement). If you use the "exit" statement somewhere in your form, you have to "form loses focus" before the exit.

Iain Sharp said ... For your point however, if all the forms are modal, does the operation Init and Cleanup work for you? You could have a global variable storing a list of components and take the last one off the list.  operation Init ... operation Cleanup ...

Ben, For what it's worth, in your case, I would have also done exactly what Iain has suggested.

Hi all Thank you for your replies; I'm currently experimenting with the implementation similar to the one Iain has suggested, and will share my final solution once I have confirmed it is functional. To share my current progress I'm still encountering two problems, these are:

• If a form is created with the "newinstance" proc command, then not made active immediately after, the context will become incorrect.
• Some developers create new forms with the "run" proc command, this seemingly doesn't implicitly call the Init operation on the newly created form. Although the documentation for run advises using the activate command it isn't considered deprecated and therefore should be supported.

Both these problems could be fixed with a hybrid solution of using the Exec trigger (called on form activation) to set the context to the current form and the implicit CLEANUP operation to set the context to the parent form. This should work for any method of creating a form as the execute trigger is always called on the form becoming active. Likewise leaving a modal form with exit command will always cause the Cleanup operation to be called (I hope!). Regards, Ben