OCS Consulting - Technology Solutions - Database Solutions - Hints & Tips: Wildcards in Assignment Files

Database Solutions - Hints & Tips

Tip 34:

Storing Data Using The Quit Trigger

When developing a UNIFACE application the method adopted for exiting a form is usually via the <ACCEPT> and <QUIT> triggers. The logic applied in the use of these triggers is usually:-

<ACCEPT>	Store any modifications and exit the form.
<QUIT>	If modifications have been made prompt the user that continuing will lose any changes. If no modifications were made simply exit the form with no action.

By use of the macro statement, the structure editor functions 'Macro "^STORE"' and 'Macro "^QUIT"' can be placed into the event input queue from the required command button.

E.g.

Two buttons "Accept" and "Quit"; the contents of the <DETAIL> trigger being 'macro "^ACCEPT"' and 'macro "^QUIT"' respectively.

This is simple enough as the accept trigger invokes the store procedure and the quit trigger has no action but to leave the form.

(NOTE The <ACCEPT> trigger will not perform any action unless coded to do so, in this case a suitable store procedure should be written and called from this trigger).

Alternative Logic

In some applications the need to allow the user to store changes at the Quit stage is required. That is, instead of prompting the user that their changes will be lost, prompting them with a message asking if they wish to save these changes prior to quitting the form - e.g.;

Problems can arise by simply coding the 'store' command into the quit trigger as unlike the <ACCEPT> trigger, Leave field, LMO and LMK triggers are not fired automatically and this could result in important code not being processed.

In a Version 7 developed application the use of the "Validation" triggers rather than "Leave" triggers for coding validation checks will alleviate this problem as the 'store' command fires these triggers.

Solution

By the use of local procs and the 'macro "^store"' statement the same store code can be activated from either the <ACCEPT> or <QUIT> triggers by issuing the macro command which is entered into the event queue and then issuing a 'return(-1)' statement which returns control to the form and then executes the contents of the store trigger (invoked by the macro command).

By tracking from where the macro was issued, an 'exit (0)' or 'exit (-1)' can be performed from within the store trigger, and thus the form is exited in the correct manner.

Method

<QUIT> Trigger

if ($formdbmod = 1 )
askmess/question "Modifications Found - Do You Wish To Store Changes First?", "Yes,No,Cancel"
if ($status = 3)	Cancel - No action just return to the form
return(-1)
else
if ($status = 2)	No - Rollback (possible locks taken out) and exit form
rollback
exit(-1)
endif
endif
else
exit(-1)	No Mods found so exit the form
endif
; will only reach this point if the answer was YES to the Question
$called_from$ = "QUIT"	Track from where exit procedure was called
call lp_store	Calls lp_store which puts the macro "^store" function in event queue
return(-1)	This line of code will be executed before the store procedure is invoked as the Macro only placed the "^store" function in the Queue.

<ACCEPT> Trigger

if ($formdbmod = 1)
	Calls lp_store which puts the macro "^store" function in event queue
$called_from$ = "ACCEPT"	Track from where exit procedure was called
call lp_store	Calls lp_store which puts the macro "^store" function in event queue
return(-1)	This line of code will be executed before the store procedure is invoked as the Macro only placed the "^store" function in the Queue.
else
exit(0)	Exit the form as no modifications were made
endif

<LPMX> Trigger

entry lp_store
macro "^store"	Place macro command in queue
end

(Remember placing a macro command in a local proc will continue with processing after the action form the macro command has been completed.)

<STORE> Trigger

call cp_store	Central store procedure
if ($called_from$ = "QUIT")
exit (-1)
elseif ($called_from$ = "ACCEPT")
exit (0)
endif

compuware_01.gif (3977 bytes)

Refresh Frames