We've learned before that the Transaction object has Events that can be programmed to control and define its behavior. As a review, let's remember the Events that are available. The Start Event defines an Action to be executed when you open and start working with the Transaction. The Track Context Event allows you to schedule what Action to take when a change is made in the Context of the Transaction Execution. What do we mean by Context? It's the Context in relation to a Screen, to a Form. When
we move within a Screen, we're changing the Context of Attributes and Variables. This information about the Context change is fundamental to define an Action to be taken. The OnMessage event, which is related to Web Notifications. The Insert, Update and Delete Events which, as we've seen, apply to the specific case of dynamic transactions and allow programming its behavior so that they're updatable. The Exit Event allows programming the actions to be executed when the transaction is already clo
sed and the After TRN Event which is triggered after the commit has been executed. Looking back at what has already been discussed about rule triggering moments, this After TRN event is executed just like the triggering moment on AfterComplete. Okay, we're now going to meet a new requirement made by the Travel Agency. We are requested that every time you work with the registration of a Tourist Attraction and After the Commit, a pop-up window be shown with a PDF with the detail of that Attraction
. Let's open GeneXus. We've already defined the PDF list named Attraction Detail, which receives by parameter the Identifier of an Attraction, and shows its detail. The question to answer now is, where do we declare the call to this procedure to achieve the required functionality? If we need to call it after the commit, then we may consider, for example, declaring a Rule in the Attraction Transaction, and conditioning it to the moment on AfterComplete. However, the requirement is to show the PDF
list in a pop-up window, and this pop-up method is not available in the Rules of a Transaction. Therefore, we can resort to the AfterTRN event. Okay, since we've applied the WorkWith pattern, We already know that GeneXus automatically adds code in this Attraction transaction and that, in particular, it adds the Return command in this After TRN event. Therefore, we must call the list before this Return command is executed, and, outside the marks of the code automatically generated as a result of
applying the pattern. From here, we'll call the Attraction detail list so that it's shown as a pop-up and pass it the corresponding Attraction ID parameter. To see it running, we press F5. We run WorkWithAttractions and we're going to to insert a new attraction. We enter the Louvre Museum, which is located in France, in Paris, and we upload its photo. and then we see the PDF file in a pop-up window with the detail we've just entered. Closing the PDF triggers the Return command and we return to
the initial screen. Note that we can condition the call to this PDF depending on the execution mode of the transaction. If we want the detail to be shown, only when a new Attraction is being inserted, and not when it's being modified or deleted, then we can write something like this. Remember that the Mode variable is a System variable that saves the Mode in which the Transaction is being executed. The value of that variable is received in the parm rule, automatically declared when the Work With
pattern is applied, and it depends on the action selected by the user in the main screen. Finally, it's worth mentioning that in Transaction Events it's not possible to make updates to the Database directly, although it is possible to work with Business Components. When we work with Business Components, as in the case of Events associated with Dynamic Transactions, we don't declare the commit command, because we're in the context of a transaction; and therefore, the Commit on Exit property is s
et to True.
Comments