Field DocPerUser

Whether this Document is defined to be per user.

Valid Values

“yes” or “no” (the default value is “no”).

Remarks

Normally, Documents are located in a place pointed by its FileName field. However, with DocPerUser set to “yes”, the corresponding document has the following behaviour:

. They are handled by the current session and their information is lost after the session finishes;

. They are located in the $WorkPath directory;

. They don’t exist at the beginning of the session and must explicitly be generated on the fly by the application.

Note: In previous versions of Zim, per user Documents were indicated by the “)” mark in the FileNome of the document. In Zim 8 and up, the DocPerUser field must be set to “yes” and the “)” mask must be there as well for compatibity issues. In future versions, this mark will be removed.

 

Multiple Windows

Using Multiple Windows

So far we have dealt with the simple case where there is only one window. Now, let’s investigate the more usual case where many windows can be active simultaneously. Assume that the above examples have been built within a database that defines customers, products, and orders and that we have created non-modal windows and programs for viewing and browsing these objects. Assume also that these new programs have been built using the Framework (i.e. they register themselves and so on) and that they have been called ProcCustomers, ProcProducts, and ProcOrders respectively.

We would want to be able to open these windows from our main application window, so the first change we must make is to add menu items to the main application window menu. For example, we might have a menu items that says “Customers…” and assign the tag “CUSTOMERS” to it. Similarly, we could have menu items with labels “Products…” and “Orders…” and give these tags “PRODUCTS” and “ORDERS” respectively. The actual labels and tags could be different of course.

To handle these new actions, we add the following lines to the main window program, MainWindowProg, after line [73].

[73.1]when vlAction = "CUSTOMERS"
[73.2]  ProcCustomers (vlStatus, "ENTERWINDOW")
[73.3]when vlAction = "PRODUCTS"
[73.4]  ProcProducts (vlStatus, "ENTERWINDOW",
[73.5]when vlAction = "ORDERS"
[73.6]  ProcOrders (vlStatus, "ENTERWINDOW")

Since there can be several windows open at one time, we must ensure that the Framework makes the windows for processing customers, products, and orders “children” of the main application window. By doing this, we can be sure that, if the user exits from the main window, all other windows are closed properly (see the discussion on EXIT and EXITAPPLICATION below). At any given time, the Framework tracks what it thinks is the current process (the one being interacted with at that time). Every time our application window gets the focus, we want to tell the Framework that this is the current process. This is done by inserting the following lines after line [75] that are executed when an ENTERWINDOW occurs.

[75.1] %%make ourselves current
[75.2]  pSetCurrentProcess ("wMainWindow")

Handling EXIT and EXITAPPLICATION also needs some changes. For example, if we are terminating the main application window, we need to tell the other windows to EXIT as well. We don’t want to build in to each window the knowledge of all other windows, so we add a new local variable to the local procedure plExecAction

[68a]              in vlAction) \
[68a.1]       local ( vlProcessId)

and replace lines [81a] to [84a] with the following.

[81b]when vlAction in ("EXIT", "EXITAPPLICATION")
[82b]    pDispatchAction (vlStatus, "EXIT", \
[83b]           "#TOCHILDREN", \
[84b]           MainState.stProcessId, "")
[84b.1] if vlStatus <> "CANCEL"
[84b.2]   plClose (vlStatus)
[84b.3]   pUnRegisterProcess (vlStatus, \
[84b.4]           MainState.stProcessId, "")
[84b.5]endif

In this new code, we first make a call to pDispatchAction. This call uses the #TOCHILDREN parameter to indicate that the EXIT action is to be sent to all the application window’s children. In this case, that means any of the windows for editing customers, products, or orders (if they are open). Notice that the application window code does not need to know who its children are or if they are open. The Framework keeps track of that.

If all processes (except the main application window) EXIT, then vlStatus is not CANCEL, then plClose is called to close the application window and then pUnRegisterProcess is called to tell the Framework that this window is terminating.

Field DirName

The name of an application directory (Directories); otherwise, the one application directory in which the associated object may exist.

Valid Values

An 18-character string, containing a valid object name

Remarks

In Directories:

DirName is the name assigned to the directory.

In other Object Dictionary entity sets:

In any entity set, the principal object’s DirName must match the DirName of its owner.

If DirName is left blank, the object may exist in any number of application directories.

In DDDescriptions, DirName is where the object being described may be found.

In DisplayForms, DirName is where the owner-display of the associated form may be found.

See Also

ConstName, DDObjectName, DDOwnerName, DisplayName, DocName, EntName, FieldName, FormName, MenuName, OwnerName, RelName, RoleName, SetName, UserName, VarName

Field FileName

The operating system name of a file or an input/output device. The file or device that the document represents.

Valid Values

Up to 256 alphanumeric and special characters (see “Remarks”, below, for details)

Remarks

Files

FileName can refer to a file that already exists, or it may contain the name of a file that the application will create.

A number of special prefix characters are available to denote particular operating system directory locations for files, as described below:

Prefix

Meaning

)

The file is located in the work directory (a “per user” file)

#

The file is located in the directory named in the ZIM= entry in the [ZIM] section of the ZIM.INI file (found in the Windows directory). This directory is normally the directory in which you installed Zim

The file is located in the database directory. The database directory is the default location for most Zim files; this special prefix is typically used with foreign directories

^

The file is located in the directory named in the IMAGEPATH= entry in the [ZIM] section of the ZIM.INI file (found in the WIndows directory). The image directory can be specified in the Screen Painter as the location for any supported image file type (e.g., bitmaps, icons, metafiles)

~

The file is located in the directory named in the CLIPPATH= entry in the [ZIM] section of the ZIM.INI file (found in the WIndows directory). The clip directory is used by the Screen Painter to store files involved in Cut, Copy, and Paste operations

 

See Distributing Database Files for more information on how to distribute files in a Zim database.

Devices

FileName can refer to an input/output device connected to your computer.

A number of special keywords are available to refer to standard devices known to the operating system. These keywords can be used in place of specific device names in the FileName field. The keywords and the device each represents are described below:

File Name

Meaning

$console

The terminal from which the application is being run

$stdin$

Standard input device as defined by the operating system

$stdout$

Standard output device as defined by the operating system

$stderr$

Output is directed to the ZimTrace window if the ZIMTRACE utility program is running. The window accumulates, displays, or logs the output to a file. If ZIMTRACE is not running, the output is discarded

$clipboard

Standard clipboard as defined by MS-Windows

 

See Also

Foreign

Field DocName

The name assigned to a document.

Valid Values

An 18-character string, containing a valid object name

See Also

ConstName, DDObjectName, DDOwnerName, DirName, DisplayName, EntName, FieldName, FormName, MenuName, OwnerName, RelName, RoleName, SetName, UserName, VarName

Field AvgSize

The number of records in the database object. An estimate of the number of records in an entity set, named set, relationship with fields or an estimate of the number of records (lines) in a document.

Valid Values

A non-negative number (vastint)

If you enter 0 or leave the field blank, an internal default value is used.

Remarks

AvgSize is used by the strategy analyzer to determine the most efficient access strategy when a database object is used in a set specification. AvgSize does not restrict the physical size of the object in any way.

Field ObjectKey

A unique identifier assigned by the Development Center.

Valid Values

A 25-character string (DEFAULT = $Null)

Remarks

ObjectKey is a unique identifier assigned by the Zim Development Center if the Object Manager (ZOM) has been enabled. End-users should not modify its value. Refer to the Development Center documentation for more information.

ObjectKey has a defined ListWidth of -1 and is not normally displayed.

Field Type

The data type of the object’s value.

Valid Values

Char, varchar, alpha, varalpha, numeric, int, longint, vastint, or date

Remarks

For more information about data types, consult the User’s Guide.

See Also

Length, Decimals

Field Size

The number of elements in a variable. Gives the size of array variables.

Valid Values

Any integer (DEFAULT = 1)

Remarks

If Size is 0 or 1, the variable is scalar and has one element. If Size is greater than 1, the variable is an array, with Size elements.

pt_BRPortuguese