Accessing a Table Buffer when it is not passed as a parameter


David MeegoThis post is a follow up to the previous posts on the Three Trigger Technique. If you have not read the posts explaining this technique, please use the links below:



Using the Dexterity Three Trigger Technique Part 1


Using the Dexterity Three Trigger Technique Part 2


The idea of the three trigger technique is to use a trigger on an unrelated function or procedure call to get the timing you require for your code.  The 1st and 2nd triggers are used to ensure that the 3rd trigger is only used when it is called from your desired parent script.


This post discusses a method that can be used in conjunction with the three trigger technique. In the example code supplied in the part 2 post, we were able to capture a reference to the table buffer we needed because the table was passed as a parameter to the parent script.  But, what happens when the table buffer you need is not available as a parameter?



Before we get to the actual code I should clarify that while I can write code to use a table which is defined in Dynamics.dic, or use pass through code with the execute() function to use a table in a third party dictionary. However, the table buffer used will be a new private instance created for the duration of the code.  To use the same table buffer as the original code requires a reference to the table buffer to be captured and stored.  Then this reference can be used or passed as a parameter.


We will discuss three methods that can be used to capture that all important table reference:


Method 1: When the table is a parameter to another function or procedure called prior to your triggering point.


You can add a fourth trigger to your scripts running before the original code of the function or procedure that passes the table as a parameter.  This trigger's purpose is just to capture the table reference so it can be used in our code later.


Example Trigger handler script

 


Method 2: When the table is attached to a form.


The following scripts demonstrate how to capture the table buffer reference after the first get table or change table command is issued against that table.  By using a global integer variable to store the trigger tag returned when registering, we are able to enable and disable the table trigger as needed.  The trigger is disabled once the reference is captured so that it does not affect performance. 


Global Procedure: Startup

 


Global Procedure: MBS_XYZ_FORM_PRE

 

Global Procedure: MBS_XYZ_FORM_POST

 

Global Procedure: MBS_XYZ_Table_READ

 


Method 3: When the table is a local instance created in a function or procedure.


This method is similar to the method above, but uses triggers on the function or procedure and has to use an unrestricted table trigger (i.e. not linked to a form). 


Global Procedure: Startup

 


Global Procedure: MBS_XYZ_Script_PRE

 

Global Procedure: MBS_XYZ_Script_POST

 

Global Procedure: MBS_XYZ_Table_READ

 


Hope you find this technique a useful addition to your arsenal.


David

Comments (1)

Skip to main content