Click above to get retro games delivered to your door ever month!

   In the generated source, a set of standard Injection Points is available.
   The position and the codification (unique identifier code of the point
   within the source) of the injection points follows a convention that
   defines the way the method is used in the naming of the codes.

   Codification of injection point within DBF() (Open files) function.

     Function: DBF()

     Code: DBFn

   where n indicates the progressive number assumed by the injection
   point inside the same method (the code of the first injection point will
   be DBF0, the second DBF1 and so on). It is necessary to pay attention to
   the assignment of the code to the points, since it is not possible to use
   a code more than once within the same Template.

   The same identifier chosen is displayed also within the Code environment
   in dBsee.

Example:

   The following example illustrates how to set a block type injection point
   in a Template, and what this will determine in the generated program. The
   command to insert in the Template to generate a Block type point is the
   following:

     .block <block_id> [descriptive text]

   Where '.block' is the command and <block_id> the identifier. For the
   name of the identifier, we suggest you used the syntax shown in the
   previous example. The descriptive text is optional, but if inserted, will
   be shown on the corresponding source row.

     . Template:

     .block DEL0 delete record
     *
     SELECT #filename()#
     DELETE
     *
     .endblock
     RETURN (.F.)

     . Generated:

     * #COD OBDEL0 * #END delete record
     *
     SELECT Articles
     DELETE
     *
     * #COD OADEL0 * #END delete record
     RETURN (.F.)

   --------------------------------------------------------------------------
   Attention - Remember that the command .block must be followed by
   the command .endblock allowing to create an 'after' injection
   point with the same base codification of the 'before' point.
   --------------------------------------------------------------------------

   The command:

     * #COD OBDEL0 * #END

   present in the generated program is formed by two fondamental parts,
   called markers. The first

     * #COD <code>

   indicates the beginning of the injection point and the second

     * #END

   specifies the end. In order for it to be used, the injection point must be
   "opened". In other words, the two markers must be placed on two lines:

     * #COD OBDEL0
     * #END delete record

   determining the beginning and the end of an injection point that in the
   following example is completed with the entering of source code. Between
   the before injection points (ex. OBDEL0) and after (ex. OADEL0)
   opened, the generator will insert the expected source automatically. The
   custom source code must be inserted within the lines identified by the two
   markers.

     * #COD OBDEL0
     IF dBaskW("Delete the record ?", "YN")="Y"
     * #END delete record
     *
     SELECT Articles
     DELETE
     *
     * #COD OADEL0
     ENDIF
     * #END delete record
     RETURN (.F.)

   The block injection points are positioned at the beginning of a function.

Injection point BEFORE

   The before injection point is usually used to execute the instructions
   before the operations performed by default by the procedure, or in
   order to conditionally skip the execution.

Example:

     * #COD OBDEL0
     IF ! Rights( UserName, RECORD_DELETE )
        dBMsgErr( "User not authorised" )
        RETURN (.F.)
     ENDIF
     * #END delete record
     *
     SELECT Articles
     DELETE
     *
     * #COD OADEL0 * #END delete record
     RETURN (.F.)

Injection Point AFTER

   The injection point at the end of a block is usually used to execute the
   instructions after those contained in a block, or to conditionally
   skip to another procedure different than the desitination procedure.

Example:

     * #COD OBDBF0 * #END opening database
     *
     IF !dfUse( "Articles" ) ; RETURN (.F.) ; END
     *
     * #COD OADBF0
     IF DEMO_VERS
        dBMsgOn( "Demo version//"+;
                 "Initialising..." )
        DELETE FOR RECNO()>10
        PACK
        dBMsgOff( )
     ENDIF
     * #END opening database
     RETURN (.F.)

   In the above example, the application verifies if running a demo version
   of the product in the injection point 'after' the opening of the
   files. If affirmative, code is added that gives an informative message and
   removes the records in excess.

Use of the BLOCK point

   The Block injection points have been studied in order to let the
   programmer, other than put custom code into the points, tell the generator
   not to generate the part of code that lies between the before injection
   point and its corresponding after point.

   This solution can be exploited to completely rewrite the functionalities
   of a procedure, without having the code that is generated automatically be
   duplicated.

Example:

   This example will illustrate:

     . a function of a Form object

     . the possibilites to intervene before and after

     . and the complete substitution of the block.

     
     *---------------*
     FUNCTION c1Dbf() // [ 02 ] OPENING DATABASE
     *---------------*
     * #COD OBDBF0 * #END // Opening database
     IF !dfUse( "Art",NIL,aFile ) ; RETU .F. ; END
     IF !dfUse( "Cli",NIL,aFile ) ; RETU .F. ; END
     * #COD OADBF0 * #END // Opening database
     RETURN .T.

   The programmer can intervene within the injection points and add parts of
   code:

     
     *-------------------------------------------*
     FUNCTION c1Dbf() // [ 02 ] OPENING DATABASE
     *-------------------------------------------*
     * #COD OBDBF0 * #END // Opening database
     IF !dfUse( "Art",NIL,aFile ) ; RETU .F. ; END
     IF !dfUse( "Cli",NIL,aFile ) ; RETU .F. ; END
     * #COD OADBF0
     IF !dfUse( "For",NIL,aFile ) ; RETU .F. ; END
     * #END // Opening database
     RETURN .T.

   If the programmer desires to intervene even on the part generated
   automatically taking, therefore, the responsibility of its maintenance,
   he/she can act within the injection points.

   As described before, it is possible not to generate the parts of code that
   lie between the injection points 'before' and 'after'.

   It is sufficient, following the example shown above, that the programmer
   'moves' the part of code generated in the injection points 'before'
   and adds, before closing the point, a line that contains the

     * #JMP

   statement, acronym for jump.

   --------------------------------------------------------------------------
   This line is generated entirely. Therefore, it is necessary not to
   forget to insert the comment marker (* or //). This will make sure that no
   errors will be verified when compiled by Clipper.
   --------------------------------------------------------------------------

   After having read the source program, the source must be regenerated in
   order to make the modifications permanent.

     
     *-------------------------------------------*
     FUNCTION c1Dbf() // [ 02 ] OPENING DATABASE
     *-------------------------------------------*
     * #COD OBDBF0
     IF !dfUse( "Art",NIL,aFile ) ; RETU .F. ; END
     *
     * #JMP // Jump to the Code after
     * #END // Opening database
     IF !dfUse("Cli",NIL,aFile) ; RETU .F. ; END //($$)
     * #COD OADBF0
     IF !dfUse( "For",NIL,aFile ) ; RETU .F. ; END
     * #END // Opening database
     RETURN .T.

   The result is that the generator, finding in the 'before' injection
   point the 'JMP' (jump) identifier, will see to jump the line of code (here
   shown with the ($$) indicator) and go directly to the 'after'
   injection point. This line will thus not be generated (even if displayed
   in the example).