CHANNEL specifies the memo file channel number (0 for memory based memos.) It may also specify the memo file ddb/buffer area or, under AMOS, point to the ddb/buffer area.

If the memo file is opened with a Basic OPEN statement, then CHANNEL must contain the open channel number. (INMEMO will use a variation of the SYSLIB routine $FLSET to locate the file ddb.)

If you wish to have INMEMO open and close the file for you (using opcode MMO'OPN and MMO'CLS) then CHANNEL must either be mapped as a file buffer or it must be a pointer to a file ddb/buffer area. The easiest method is to map CHANNEL as follows:

MAP1 CHANNEL,X,800

(The size must be large enough to contain a file ddb and buffer; we recommend 800 bytes to allow for some minor expansion.) Also note that you cannot use this mapping for NO-FILE mode (described below), since there is no clean way to give it a numeric value.

(AMOS only.) As an alternative, you can allocate an 800-byte area somewhere and set CHANNEL to point to it. This is an advanced technique and is probably only useful to programmers using other host languages besides Basic. If used, the format of CHANNEL must be a standard 4-byte long word (high word, low word).

Under A-Shell, as a convenience, you may map CHANNEL as a string and load it with the file specification of the memo file and INMEMO will automatically take care of opening and closing the file for you. If the file does not exist, INMEMO will automatically create it (32K.) INMEMO will also automatically expand it as needed. (This shortcut simplifies casual use of INMEMO considerably, since it eliminates the need to open and close the file, as well as the need to use the MAKMMO utility to create the file and the EXPMMO utility to expand it.)

INMEMO will determine whether CHANNEL is a file channel, a ddb/buffer, or a pointer to a ddb/buffer by examining its size and value.

If CHANNEL is 0, INMEMO operates in NO-FILE mode. In this mode, it does all of its I/O through the TEXT parameter. For input, the TEXT should be set up as for preloading characters - place a tilde (~) after the prompt and follow with the text to be loaded. The only difference is that these characters will be loaded directly into the memo-editing buffer, rather than processed as if you were typing them. Consequently, the text should not include any control characters except carriage returns (optional) to terminate each line. INMEMO will do its own word wrapping if necessary to make the lines fit. We decided to do it this way because the display comes up much faster if all the formatting is done in advance of the display, and it also eliminates having to do any scrolling if the memo text extends beyond the window boundaries. Just as with a normal disk-based memo, the first `page' will display initially, and you can always use the scrolling commands to reposition the window.

On output, (if you set the MMO'EDT bit), it writes the updated memo text back to the TEXT parameter. The format of the returned memo is identical to the format during editing, which is defined by the VSPEC parameter. It is simply a linear array of VWIDTH times VROWS characters, with all lines padded with spaces and no line terminating characters. The only terminator is a null byte that is placed after the last non-blank character in the memo. (E.g., if the VSPEC format was 20 rows of 80 characters, and the returned memo ended in the middle of the 5th row, then 4 rows of 80 characters would be output.) Also note that the maximum number of characters to be output in this mode is limited to the smaller of the TEXT parameter size, the memo size, and 64K characters.

Note that NO-FILE mode can be used in conjunction with any of the other modes, except the search mode and table modes. For example, you can use it with display-only, display-with-scrolling, editing, or menu mode.

Why use this NO-FILE mode? Obviously, if you are supplying the text directly, the display-only modes are really no more than glorified PRINT statements. But that may be very handy in some situations, particularly when taking advantage of the scrolling and automatic formatting capabilities. The editing mode may be useful as an extended INPUT (or INFLD) call, allowing you to directly input a `whole bunch' of text at a time, (possibly storing it in some other file system.) Menu mode may be the most useful, since it is perfect for pop-up menus. Although there may be an argument for storing pop-up menus on disk, creating them on the fly with NO-FILE mode is much faster. This is particularly handy for selecting among choices that are stored in another type of data file. For example, you could implement a customer lookup routine which used a normal input field to input a partial name, then scanned a key file locating all the customers that matched the partial key and built a list of them in memory, then used INMEMO to display and select the desired customer from the list.

A very simple program to demonstrate no-file mode is provided with the INMEMO release called TSTNFL.BAS. Just compile it, load INMEMO.SBR, and RUN it (and then look at the source code.) It demonstrates many of the possibilities for no-file memos.