Answers in this category:
Is the documentation for the CNV TEXT statement wrong regarding the use of occurrence "000"?
How do I get the my current APPX Process ID
ILF verb shortcuts (abbreviations).
GOSUB/SUBR/COPY exit considerations.
GOSUB/COPY/SUBR usage considerations?
Variable Scoping considerations with GOSUB/COPY and SUBR.
Load time, memory usage, and caching considerations when determining using GOSUB, COPY and SUBR.
Why are there lowercase I/O Verbs in ILF?
ILF Option 94
ILF Force Save Option 88
ILF Option 95
Text and Icon Position via ILF --- WIDGETs
I keep loosing my toolbar when I go in and out of the Image Editor.

In Chapter 4-6: ILF Keyword Reference <CNV TEXT> of the designer manual, under CNV TEXT, it says:

    ••••• CNV TEXT ••• •••••••••••••••••••••• ••• =  ••• •••••••••••••••••••••• •••
    (1)            (2) (3)                    (4)    (5) (6)                    (7)

Restrictions

When all occurrences of the sending field are selected as the CNV TEXT data (by entering occurrence number 000), all occurrences are treated as a single, rectangular alpha field. When the data is copied from the sending field, a check is made to ensure that soft spaces are compressed, ensuring that the next “word” is separated from the previous one by just one space.

... should the first "sending field" text instead be Destination field?  

With respect to the second one, the ILF editor that lets you set it up appears to be broken.   It won't take an occurrences of "000" on the RHS (Source side), it just disappears, and is treated normally (as if it were '1').   The '000' CNV TEXT spec only works on the LHS (Destination)...

Unless both the LHS and RHS fields are multi-occurrence.  In which case the ILF editor will accept 000 for the RHS occurrence.

There's something I'm not understanding here.

-pat-

======================================================================
SUBROUTINE  Process Name:     GET PROCESS ID
 
      GOSUB    --- GET CONFIGURATION INFO 
      SET      --- CONFIG TYPE                =      PID 
      READ     --- CONFIG                 HOLD 0      BY CONFIG TYPE 
F     CANCEL    unexpected error trying to READ "--- CONFIG" 
      SET      --- TEMP 32                    =  --- CONFIG DATA 
      *        --- TEMP 32 contains the unique Process ID 

====================================================================== 

The following list of shortcuts can be used while entering statements in the ILF editor.

S  =  SET
W  =  WRITE
A  =  APPEND
G  =  GOSUB
I  =  IF
T  =  TRAP

BA (or BEG A) =  BEG AT
BR (or BEG R) =  BEG READ
BL (or BEG L) =  BEG LOOP

EA (or END A) =  END AT
ER (or END R) =  END READ
EL (or END L) =  END LOOP

CA    =  CALC
CO    =  COMPUTE
READN =  READNEXT
R     =  READ
REW   =  REWRITE

RECIEVE = RECEIVE   (auto correct)

If you use an EXIT or RETURN statement in the subroutine, then you may be setting yourself up for a problem.

Exiting a subroutine with a RETURN for GOSUB calls will generate an EM Compiler error if you try to call it as a SUBR. A SUBR is a standalone process that now has a RETURN without a GOSUB.

A worse problem is using an EXIT in the subroutine. This works fine when you call it as a SUBR. It also does not complain when you call it as a GOSUB. The problem is that the GOSUB brings the code inline. This means that the EXIT statement in the subroutine will also exit the calling code. This can be handy if this is what you really intended to do. This can be bad if you forget and call it with a GOSUB intending on it to return back when the GOSUB is done.

Try not to include a RETURN or EXIT in an external subroutine. Since you can never be completely sure of how it will be called in the future.

COPY and GOSUB are almost identical in that they both bring the code inline 
to your process.  In fact, when you code something like:


 GOSUB    XXX SUBROUTINE


where SUBROUTINE is *not* a label in the current event point, then APPX will 
create


 LABEL    SUBROUTINE
 COPY     XXX SUBROUTINE
 RETURN


The major difference between COPY and GOSUB is that GOSUB has its own set of 
T/F flags, whereas COPY just copies the requested code into the event point 
at that location, and if there are any T/F flags involved, the copied routine 
better know about them.  Example:


   READ   <some file>
F  COPY   <routine a>


The code in routine <routine a> will have the F flag set in the first position 
when it starts running, and any T/F flags it changes will be visible to the 
code following the COPY.  If the copy was a GOSUB instead, then in <routine 
a>, the first T/F flag would not be set, and any T/F  flags it changes would 
*not* be visible to the statements following the GOSUB. 


A SUBR is another process invocation, so:


 - the code exists as a separate process, which is sometimes required.
   For example, you can call SUBR within a BEG READ/END READ loop, and
   the routine can also do a BEG READ/END READ on the same file without
   any problems.


 - you can control sharing via the SUBPROCESS/RELATED/DETACHED invocation


 - the code is *not* compiled into the calling program, thus reducing EM
   size (but who cares, really).


 - you cannot exit the routine with a RETURN, you must have an END or
   EXIT, or just run out of statements.


 - takes longer to invoke, as a separate process needs to be brought
   into memory and control passed to it, and then returned to the caller.
   Not a problem for data entry programs but can add run time if it's
   in a update & gets invoked hundreds of times.


Because of the difference in exiting a SUBR (with END/EXIT) vs. a GOSUB (with 
RETURN), you can't really call the routine one way or the other.  You must 
decide if it's going to be invoked as SUBR or GOSUB, and code accordingly.  
If a SUBR attempts to exit with RETURN, you will get a run time error, however,
if a GOSUB encounters an END/EXIT, then you have just ended the execution of 
the entire Event Point, not just that subroutine.  This is a subtle programming 
error that can lead to difficult to track down bugs, ie, sometimes a post just 
skips part of the updating for a record because someone put an END instead of 
RETURN in a GOSUB'd routine.


As to which one to use:


 - COPY if you just want to bring in some straightforward code, i.e., for
   this current ORDER2 record, read the ORDER1, CUSTOMER and PRODUCT files.


 - GOSUB if you need to preserve the T/F flags


 - SUBR if you *need* the special advantages it offers.

This concept deals with variable values and memory as you branch into and  
return from subroutines.  If you have a process that is using --- AI as a 
counter and at some point in the code you branch into a subroutine and return, 
the variable --- AI may have been changed (or stepped on) by the subroutine.  
That is because GOSUBs and COPYs bring the code into the current process.  
You can have the subroutine STORE and RESTORE any variables it uses, but that 
only works one level deep.  

If a subroutine is called by a GOSUB and it in turn calls another subroutine 
with a GOSUB, then the STORE in the second subroutine will step on the STARE 
done by the first subroutine.  This is because there is only one STORE/RESTORE 
area per variable/process. 

Example:

Process: TEST
SET      --- AI                 =     10
GOSUB    AAA DO SOMETHING
SET      --- BI                 = --- AI
*
END
*
LABEL    DO SOMETHING
STORE    --- AI
SET      --- AI                 =     20
GOSUB    AAA DO SOMETHING ELSE
RESTORE  --- AI
RETURN
*
LABEL    DO SOMETHING ELSE
STORE    --- AI
SET      --- AI                 =     30
RESTORE  --- AI
RETURN

So, instead of --- BI getting a value of 10, it would get a value of 30.  This 
is because the second GOSUB'd routine wrote over the STORE buffer created by 
the first routine.

On the other hand, if you use SUBR calls, then each SUBR routine contains it's 
own STORE/RESTORE buffer area that can never step on the parent process 
STORE/RESTORE buffer or be stepped on by any child process the SUBR calls.  
This way, you are safe to use any variable as long as you STORE it first and 
RESTORE it when done.  Process sharing characteristics are also handy for this.
If you call SUBRs as related, and SUBPROCESS variables are local and any 
RELATED variables are shared.  This also allows for easy recursion.

The downside, is that there may be a very slight, theoretical, performance penalty since you are branching between separate processes, but I doubt this is a measurable difference unless you are very low on memory and other modules have to be cached back in.

APPX 4.1.3 has new I/O statements, with different formats than the prior I/O statements. To prevent conflicts, instead of replace the APPX I/O statements, we added new ones. But, we wanted the new one to have the name of the old ones.

Our solution was to convert the current I/O statement names from upper to lower case, then have the new statements be the names with uppercase.

So, the old I/O statements are still there and work. A lower case "read" is the old READ statement and an upper case "READ" is the new I/O statement.

The statements are converted as you edit ILF code. When an ILF event point series is loaded into the ILF editor, the "read" statements are converted to "READ" statements. When you save the code, the I/O statements have been updated to the new I/O statement format.

If you select "upper/lower" with opt-6, the command goes in as "read" instead of "READ", and the remainder of the line uses the old format (8-character file name, etc.) instead of the new. It also does not verify the key path on entry, as READ does.

The results of performing an Opt-94 from within the ILF editor depends on the statement at which the cursor is currently positioned and sometimes where the cursor is positioned within the statement.

If you're positioned to a statement that names a label or a process (GOSUB, SUBR, INPUT, etc.), then your cursor can be anywhere on that line and Opt-94 will take you to either the local label, or the process.

Some statements will jump to the DD, not to a process. In those cases you must have your cursor positioned within the field name on the statement. Some statements can contain more than one field name (like IF, APPEND, SET).

With a statement like BEG READ, you can jump to 3 different places. Based on the cursor position, you can jump to the FILE, the FIELD, or the END READ.

If you're not positioned somewhere where ILF Browse can determine where to jump to, then it invokes Xcopy logic. This is the beginning of an enhanced Xcopy that hasn't been implemented yet. For example, you might want to ILF Browse to a subroutine and mark some statements to be Xcopy'd. Someday you should be able to do that.

 
Text Position    WIDGET ALIGN HORIZ  WIDGET ALIGN VERT
---------------- ------------------  -----------------
{null}           {null}              {null}
CENTER           CENTER              CENTER
TOP              CENTER              TOP
RIGHT            RIGHT               CENTER
BOTTOM           CENTER              BOTTOM
LEFT             LEFT                CENTER
UPPER LEFT       LEFT                TOP
UPPER RIGHT      RIGHT               TOP
LOWER RIGHT      RIGHT               BOTTOM
LOWER LEFT       LEFT                BOTTOM


                 WIDGET TEXT  WIDGET TEXT  WIDGET TILING 
Icon Position     POS HORIZ    POS VERT     MODE 
---------------- -----------  -----------  -------------
{null}           {null}       {null}       {null}
BEHIND TEXT      CENTER       CENTER       {null}
ABOVE TEXT       CENTER       BOTTOM       {null}
TRAILING TEXT    LEFT         CENTER       {null}
BELOW TEXT       CENTER       TOP          {null}
LEADING TEXT     RIGHT        CENTER       {null}
ABOVE & LEADING  RIGHT        BOTTOM       {null}
ABOVE & TRAILING LEFT         BOTTOM       {null}
BELOW & TRAILING LEFT         TOP          {null}
BELOW & LEADING  RIGHT        TOP          {null}
EXPAND TO FILL   {null}       {null}       EXPAND
EXPAND PROP'L    {null}       {null}       TILE