$instancemod vs. $formmod

Author: gianni.sandigliano@unifacesolutions.com (gianni)

I am reporting here a question I got few days ago... A VAR is in the process to migrate an old Uniface customer to a new version of the same warehouse management application. This customer is used to an OLD Standard & Guidelines where the user was warned when exiting a form having changed something; this behaviour was managed in the <QUIT> trigger checking $formmod or $formdbmod functions. The new application version is Windows based and have a NEW Standard & Guidelines in place due to a wide use of non-modal forms. This new Standard & Guidelines version the application moved away from warning the user when exiting having changed something because the VAR claims it was NOT able to implement a similar functionality really working with Uniface9 in a non-modal environment. Basic reasons reported are: 1) the different way $formmod and $instancemod are implemented: - $formmod (and $formdbmod) are Uniface environment variables in its own - $instancemod (and $instancedbmod) are an OR calculation on $occmod and $occdbmod 2) while $formmod could be managed at program level with reset instruction after inizialing fields with code this opportunity is not available with $instancemod. When I received the question/issue I do not have an immediate answer in my pocket of experiences. Next week I will try to identify a solution but in mean time: does someone have suggestions? Thanks to all in advance. Gianni

3 Comments

  1. Not quite sure I understand the question. Your application is setting $formmod explicitly (eg. '$formmod = 1' or 'set $formmod')? Is that correct? And now you are not able to do the same with $instancemod? If this is the case, when you set $formmod, is this in a central location (include proc, global proc, defined local proc), if it is, then could you assign a value to a painted field to ensure the $instancemod is set. (eg. 'NAME.PERSON = NAME.PERSON')? Alternatively, to 'reset' $instancemod, which of course is not available, you could consider 'release', 'clear', or something else that set $instancemod to '0'.


    Author: rkrite (rkrite@gmail.com)
  2. I have not yet time to build a small example....but I could add details here. The need is to warn the end user when he/she ask to leave a component only when he/she has directly changed some data on the component. The issue here is not forcing those status functions to be TRUE but resetting them to FALSE when needed! In every components dealing with data if the user must be warned when leaving having changed something, steps to implement are: 1) Getting input parameters and (when needed) extracting related data 2) Initializing default data (remember: an assignment always set $formmod and $formdbmod after a retrieve!) 3) Resetting $formmod or $formdbmod 4) Having the user manipulating the session under his/her full responsibility 5) Checking $formmod or $formdbmod to warn the user if he/she tries to quit having changed something Having the opportunity to reset $formmod or $formdbmod AFTER default data initialization it is mandatory to clearly identify the part of the session under the full user responsibility. In a NON MODAL situation where $instancemod and $instancedbmod must be used, this logic could be implemented in Uniface in an effective and consistent way? It should be remembered $instancemod and $instancedbmod are tightly coupled with $occmod or $occdbmod and they cannot be reset (...AFAIK...) Thanks for any thoughts on this subject! Gianni


    Author: gianni (gianni.sandigliano@unifacesolutions.com)
  3. There are several statements that change/reset that value of $instancedbmod and $instancemod to 0. These may be considered? "clear" is one that comes to my mind firstly. Like you said, $occmod is tightly coupled with $instancemod. If $occmod is TRUE, then of course $instancemod is TRUE. It is also the case when the modified occurrence is "clear"ed or "release"d, then $occmod is no longer TRUE, and therefore, if that was the only modification in the instance, then $instancemod is also no longer TRUE. And then of course everyone is happy.


    Author: rkrite (rkrite@gmail.com)