Skip to main content

Determine trigger/proc entry info

  • May 30, 2019
  • 7 replies
  • 1 view
R

Is there a proc function that can determine which trigger/proc entry code is executing from?  I've designed a global message generation routine in which I pass in the Trigger Name and Entry Name (if applicable).  However, if I move the code to a different trigger and/or change the Entry name, I'll have to remember to change that info.


Example:  I have an Entry in Entity_Name Local Proc Modules named GetUserInfo.  In this entry I determine I want to log some information so I pass a list of something like $EntName;"Local Proc Modules";"GetUserInfo" to my global messaging routine.


Ideally, I'd like to pass Uniface-generated information instead (something like $EntName;$Trigger;$EntryName").

Thanx,

..Rob..

7 replies

Iain Sharp
Forum|alt.badge.img+5
  • Iain Sharp
  • Inspiring
  • May 30, 2019

Is there a proc function that can determine which trigger/proc entry code is executing from?  I've designed a global message generation routine in which I pass in the Trigger Name and Entry Name (if applicable).  However, if I move the code to a different trigger and/or change the Entry name, I'll have to remember to change that info.


Example:  I have an Entry in Entity_Name Local Proc Modules named GetUserInfo.  In this entry I determine I want to log some information so I pass a list of something like $EntName;"Local Proc Modules";"GetUserInfo" to my global messaging routine.


Ideally, I'd like to pass Uniface-generated information instead (something like $EntName;$Trigger;$EntryName").

Thanx,

..Rob..

There are compile time constants for at least two of those.

"<$entname>" will produce the entity name. 

"<$triggerabbr>" will produce the trigger abbreviation. 

"<$fieldname>" will produce the field name. 


Alternatively, you can look at the $proccontext("STACK"), which shows the entire call stack as a list of lists. 

Depending where you look at this (inside your global routine (Global proc?) then the point which called it is the second or third entry in the list. 

We have a global proc for logging which basically decodes the entire stack to save the point in the program at which the error occurs, and how it got there. 

You need to look at the values in there for different points in the program (component triggers/operations/lpms, entity triggers/operations/lpms and field triggers/operations/lpms. 

The $proccontext has the advantage of being coded once in the error routine, rather than in the call. 


Iain


Iain Sharp : Head of Technical Services, Jonas Metals Software
R
  • Rob Maciok
  • Author
  • Participating Frequently
  • May 30, 2019

There are compile time constants for at least two of those.

"<$entname>" will produce the entity name. 

"<$triggerabbr>" will produce the trigger abbreviation. 

"<$fieldname>" will produce the field name. 


Alternatively, you can look at the $proccontext("STACK"), which shows the entire call stack as a list of lists. 

Depending where you look at this (inside your global routine (Global proc?) then the point which called it is the second or third entry in the list. 

We have a global proc for logging which basically decodes the entire stack to save the point in the program at which the error occurs, and how it got there. 

You need to look at the values in there for different points in the program (component triggers/operations/lpms, entity triggers/operations/lpms and field triggers/operations/lpms. 

The $proccontext has the advantage of being coded once in the error routine, rather than in the call. 


Iain


Perfect. I wanted to do it all in the messaging routine anyway but didn't know that functionality existed. I'll parse the stack. Thanx!


Sample output.  I can work with this! (wish Uniface wouldn't UpperCase everything tho):

TYPE=MOD

MODID=mESHOWSINGLENOMENTITY

MODNAM=ESHOWSINGLENOMENTITY

TRIG=_detail

TRIGGER=DTLF

LNR=48

LIN=SPROCCONTEXT = $ProcContext("STACK")

OBJTYPE=FRM

APSNAM=UNI

CPTNAM=XXXXXXXXXX

INSNAM=XXXXXXXXXX

FIELD=XXXXXXXXXX

ENTITY=XXXXXXXXXX

MODEL=XXXXXXXXXX


Ingo Stiller
Forum|alt.badge.img+3
  • Ingo Stiller
  • Participating Frequently
  • June 3, 2019

Is there a proc function that can determine which trigger/proc entry code is executing from?  I've designed a global message generation routine in which I pass in the Trigger Name and Entry Name (if applicable).  However, if I move the code to a different trigger and/or change the Entry name, I'll have to remember to change that info.


Example:  I have an Entry in Entity_Name Local Proc Modules named GetUserInfo.  In this entry I determine I want to log some information so I pass a list of something like $EntName;"Local Proc Modules";"GetUserInfo" to my global messaging routine.


Ideally, I'd like to pass Uniface-generated information instead (something like $EntName;$Trigger;$EntryName").

Thanx,

..Rob..

This is a global function wich I did implement to get the caller instance.
If you want to get the entry just one step up, you have to modify this routine a little bit 🙂

Ingo


ENTRY GF_CALLER_INS
  returns string
  params
    string v_PARA:INOUT
  endparams
  variables
    string v_PROCCONTEXT_STACK
    string v_ITEM
    string v_INSTANCE,v_INSTANCE_M
  endvariables
  v_PROCCONTEXT_STACK = $proccontext("STACK")
  v_INSTANCE_M=$instancename()
  FORLIST v_ITEM IN v_PROCCONTEXT_STACK
    v_INSTANCE=$item("INSNAM",v_ITEM)
    IF(v_INSTANCE="" & $item("OBJTYPE",v_ITEM)="APS") v_INSTANCE="*APS"
    IF(v_INSTANCE!="" & v_INSTANCE!=v_INSTANCE_M)
      $status=0
      RETURN(v_INSTANCE)
    ENDIF
  ENDFOR
  $status=-57 ; UACTERR_NO_INSTANCE
  RETURN("")
END ; GF_CALLER_INS
Michael Taylor

Is there a proc function that can determine which trigger/proc entry code is executing from?  I've designed a global message generation routine in which I pass in the Trigger Name and Entry Name (if applicable).  However, if I move the code to a different trigger and/or change the Entry name, I'll have to remember to change that info.


Example:  I have an Entry in Entity_Name Local Proc Modules named GetUserInfo.  In this entry I determine I want to log some information so I pass a list of something like $EntName;"Local Proc Modules";"GetUserInfo" to my global messaging routine.


Ideally, I'd like to pass Uniface-generated information instead (something like $EntName;$Trigger;$EntryName").

Thanx,

..Rob..

Hi Rob,

Be aware the value of <$triggerabbr> is the name of the container which, in version 10, has changed - see <$triggerabbr> for more info.

Mike

Ingo Stiller
Forum|alt.badge.img+3
  • Ingo Stiller
  • Participating Frequently
  • June 3, 2019

Hi Rob,

Be aware the value of <$triggerabbr> is the name of the container which, in version 10, has changed - see <$triggerabbr> for more info.

Mike

This is very logical 🙂
In UnifAce 10 there is only one big "pot" of proccode for each component/entity
<$triggerabbr> is the name of this container and not the name of a specific TRIGGER, OPERATION, ENTRY, ...
UnifAce should change "<triggerabbr>" to "<containerabbr>" to clearify thsi 🙂

Ingo

Michael Taylor

Hi Rob,

Be aware the value of <$triggerabbr> is the name of the container which, in version 10, has changed - see <$triggerabbr> for more info.

Mike

There were many discussions at the time about what to do with <$triggerabbr> in the context of Uniface 10 code containers. One option was to change the name of the constant; however, as this would cause incompatibilities in existing applications, we decided to keep the name but allow it to be redefined. The new #startdefine and #enddefine precompiler directives were, in part, introduced to limit the scope of this constant.

Ingo Stiller
Forum|alt.badge.img+3
  • Ingo Stiller
  • Participating Frequently
  • June 4, 2019

Hi Rob,

Be aware the value of <$triggerabbr> is the name of the container which, in version 10, has changed - see <$triggerabbr> for more info.

Mike

Hi Mike

#startdefine is nice, but ... 🙂

The question was not, how could I use precompiler constants in a local context but how to get info about the "trigger" in which I'm doing my coding
e.g on have a global include to check wether the component got focus or loose it, so you put this include in FRGF resp. FRLF
In this include there is a line like this
 call GP_DO_IT("<triggerabbr>")

Perfect in UnifAce 9 but in UnifAce 10, this not longer a usefull statement 😔

Ingo




Recent badge winners

Explore all badges
Terms & ConditionsAccessibility statement