See email from Susan, contents below. This will become a higher priority once we have all Netbuilder components successfully running in UniData.
PRC will do an immense number of things, including check the particular file or component, the account you are in, the user clearance, the type of project the correct module – tons of stuff. It can be coded for special behaviors that must happen to the item (like compile or bring along the “dot-prefix-field defn”).
It will also let the user know if the item they are attempting to edit is checked out to someone else (another project) and can offer to make a separate branch copy, or various other options. In order for PRC to offer some of the more sophisticated options it has to be able to interact with the user. If there is a way to display dialog box / choices let me know. Otherwise, PRC can send back codes for whether the procedure can continue and a message that can be displayed on your end. This is a much more limited way to use PRC so we will want to evolve this however we must to give the user the ability to respond and make choices. But we can keep it pretty simple initially:
After the designer tool has read the software component in, call "PRC.PRELOG.B" with 5 arguments:
· FILE.NAME The file where the software component is stored, such as the ‘PROCESS’ file.
· ITEM.NAME The name of the screen, field, program, whatever it is.
· P.TYPE This can be ‘ED’ a lot – or all the time. The advantage of having different P.TYPEs is if there is additional behavior that needs to happen, such as PRC knows that an ‘FD’ type (field definition in SB+) has two items, the field item and the dot-in-front field item. Same with ‘SD’ (screen definition) items, PRC knows that these have TXT and GUI and more items. So if we are going to use different P.TYPES I need to set up the special behavior. ED items can be compiled or not, that is set up by file in a different setup/configuration place.
· GONO PRC sends back a ‘0’ if all is well and the read is allowed. Other things it might send back are ‘1’ all is well but display the message in P.MSG. 2, 3 and 4 are various degrees of fatal and, at least initially, should display the message in P.MSG and disallow the read.
· IN.ACTION SB designates 1 for a new item 2 for a modified item and 3 for a delete.
· IN.RECORD The item that is read in, the program or paragraph process or field item.
· P.MSG A message that PRC sends back that you can display passively or with a required . We can get more elaborate, but this for now.
Before the designer tool writes out the item, call "PRC.LOG.B" with 6 arguments:
· FILE.NAME The file where the software component is stored, such as the ‘PROCESS’ file.
· ITEM.NAME The name of the screen, field, program, whatever it is
· P.TYPE This can be ‘ED’ a lot – or all the time. The advantage of having different P.TYPEs is if there is additional behavior that needs to happen, such as PRC knows that an ‘FD’ type (field definition in SB+) has two items, the field item and the dot-in-front field item. Same with ‘SD’ (screen definition) items, PRC knows that these have TXT and GUI and more items. So if we are going to use different P.TYPES I need to set up the special behavior. ED items can be compiled or not, that is set up by file in a different setup/configuration place.
· GONO PRC sends back a ‘0’ if all is well and the write is allowed. Other things it might send back are ‘1’ all is well but display the message in P.MSG. 2, 3 and 4 are various degrees of fatal and, at least initially, should display the message in P.MSG and disallow the write.
· IN.ACTION SB designates 1 for a new item 2 for a modified item and 3 for a delete.
· IN.RECORD The item that is read in, the program or paragraph process or field item. Before the change was made. (“Orig.rec”)
· CUR.RECORD The item as it is, after the change, what will be written (your program will still write it.)
· P.MSG A message that PRC sends back that you can display passively or with a required . We can get more elaborate, but this for now.
See email from Susan, contents below. This will become a higher priority once we have all Netbuilder components successfully running in UniData.
PRC will do an immense number of things, including check the particular file or component, the account you are in, the user clearance, the type of project the correct module – tons of stuff. It can be coded for special behaviors that must happen to the item (like compile or bring along the “dot-prefix-field defn”).
It will also let the user know if the item they are attempting to edit is checked out to someone else (another project) and can offer to make a separate branch copy, or various other options. In order for PRC to offer some of the more sophisticated options it has to be able to interact with the user. If there is a way to display dialog box / choices let me know. Otherwise, PRC can send back codes for whether the procedure can continue and a message that can be displayed on your end. This is a much more limited way to use PRC so we will want to evolve this however we must to give the user the ability to respond and make choices. But we can keep it pretty simple initially: After the designer tool has read the software component in, call "PRC.PRELOG.B" with 5 arguments:
· FILE.NAME The file where the software component is stored, such as the ‘PROCESS’ file. · ITEM.NAME The name of the screen, field, program, whatever it is. · P.TYPE This can be ‘ED’ a lot – or all the time. The advantage of having different P.TYPEs is if there is additional behavior that needs to happen, such as PRC knows that an ‘FD’ type (field definition in SB+) has two items, the field item and the dot-in-front field item. Same with ‘SD’ (screen definition) items, PRC knows that these have TXT and GUI and more items. So if we are going to use different P.TYPES I need to set up the special behavior. ED items can be compiled or not, that is set up by file in a different setup/configuration place. · GONO PRC sends back a ‘0’ if all is well and the read is allowed. Other things it might send back are ‘1’ all is well but display the message in P.MSG. 2, 3 and 4 are various degrees of fatal and, at least initially, should display the message in P.MSG and disallow the read. · IN.ACTION SB designates 1 for a new item 2 for a modified item and 3 for a delete. · IN.RECORD The item that is read in, the program or paragraph process or field item. · P.MSG A message that PRC sends back that you can display passively or with a required. We can get more elaborate, but this for now.
Before the designer tool writes out the item, call "PRC.LOG.B" with 6 arguments:
· FILE.NAME The file where the software component is stored, such as the ‘PROCESS’ file. · ITEM.NAME The name of the screen, field, program, whatever it is · P.TYPE This can be ‘ED’ a lot – or all the time. The advantage of having different P.TYPEs is if there is additional behavior that needs to happen, such as PRC knows that an ‘FD’ type (field definition in SB+) has two items, the field item and the dot-in-front field item. Same with ‘SD’ (screen definition) items, PRC knows that these have TXT and GUI and more items. So if we are going to use different P.TYPES I need to set up the special behavior. ED items can be compiled or not, that is set up by file in a different setup/configuration place. · GONO PRC sends back a ‘0’ if all is well and the write is allowed. Other things it might send back are ‘1’ all is well but display the message in P.MSG. 2, 3 and 4 are various degrees of fatal and, at least initially, should display the message in P.MSG and disallow the write. · IN.ACTION SB designates 1 for a new item 2 for a modified item and 3 for a delete. · IN.RECORD The item that is read in, the program or paragraph process or field item. Before the change was made. (“Orig.rec”) · CUR.RECORD The item as it is, after the change, what will be written (your program will still write it.) · P.MSG A message that PRC sends back that you can display passively or with a required. We can get more elaborate, but this for now.