Field RelPerUser

Whether this relationship is defined to be per user.

Valid Values

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

Remarks

The RelPerUser field only applies to Relationships with fields because there is no physical file to be handled.

Normally, Relationships with fields belong to the database and are managed by ZimServer. However, per user Relationships have these differences:

. 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 suffer any locks because they belong to the current user and no other users can access them;

. They don’t exist at the beginning of the session and must explicitly be created (or recreated) at any time by the application via the command INITIALIZE PERUSER. There is no need to keep a “storage” full of empty copies of all per user Relationships used by the Zim  application.

In previous versions of Zim, per user Relationships were indicated with the “)” mark in the AREAS.ZIM file. This is no longer needed and any such entries will flagged with an error.

Field EntPerUser

Whether this entity set is defined to be per user.

Valid Values

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

Remarks

Normally, entity sets belong to the database and are managed by ZimServer. However, per user entity sets have these differences:

. 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 suffer any locks because they belong to the current user and no other users can access them;

. They don’t exist at the beginning of the session and must explicitly be created (or recreated) at any time by the application via the command INITIALIZE PERUSER. There is no need to keep a “storage” full of empty copies of all per user entity sets used by the Zim  application.

In previous versions of Zim, per user entity sets were indicated with the “)” mark in the AREAS.ZIM file. This is no longer needed and any such entries will flagged with an error.

DDE Services

Zim provides DDE services for applications through the function $DDEFunction. These DDE services include the ability to send data to another application, retrieve data from another application, and pass commands to another application. While you can write your own implementation of $DDEFunction, Zim provides a standard implementation in the form of a Dynamic Link Library (DLL) and several Zim programs that provide an easy-to-use interface to the services of the DLL.

Using the DDE Services Provided by ZIM
The actual name of the DLL accessed by $DDEFunction is defined by the DDEFUNC entry in the registry. If you do not have a DDEFUNC entry, the name of the DLL is assumed to be z32dde.dll and the file is assumed to be in the same directory in which your Zim software was installed. Upon Zim installation, the registry value of DDEFUNC is not set because Zim automatically assumes the required values on its absence.

Using Special DDE Services Provided by the User

If you want to use your own special DDE services support, you must build a DLL that follows the same standards as any $UserFunction and set the DDEFUNC registry like this example before starting your Zim for Windows session:

DDEFUNC=C:\MYCODE\MYDDE.DLL

Invoking the DDE Services
The standard DDE services provided by Zim can be accessed in two ways:

through the set of Zim programs that provide an interface to the DDE DLL (z32dde.dll)
by calling $DDEFunction directly (always referencing z32dde.dll)
These two ways distinguish from each other from the fact that the Zim programs are easier to deal with because they provide all error handling and parameter checking and converting. On the other side, the $DDEFunction usage can provide more flexibility but requires more attention from the programmer.

Invoking the DDE Services

Invoking the DDE Services Through the Zim Interface Programs
Your Zim installation provides a set of Zim programs as a means of an easy interface to DDE services. These programs are located in the $DeployServices directory that must be accessed via the command prior to any reference to these programs:

access $DeployServices

The programs are all compiled, but the corresponding source code is located in the operating system directory “dpserv/dpsdocs”. They implement five different operations against the DDE services as follows:

DDEConnect, which connects to the desired service;

DDEExecute, which executes a specific operation on the service;

DDEPeek, which gets some value from the service;

DDEPoke, which sets any values to the service;

DDEDisconnect, which disconnects and ends to conversation to the service.

Please refer to the corresponding documentation of each of these commands for more details.

Syntax

Invoking the DDE Services Directly Through $DDEFunction
The DDE services can be accessed by invoking the Zim function $DDEFunction directly. $DDEFunction is invoked with the syntax

$DDEFunction ( p1, p2, p3, ... )

where p1, p2, and so on, indicate the desired DDE service and the data required by that service. Specifically, p2 passes the desired operation to be performed against the DDE services. The operations are exactly the same as those provided by the Zim Interface Programs.

See Also

$DDEFunction

Selecting by the Defined Property

Objects can be selected by querying the defined property using the selection criteria “d”. All objects that are defined (i.e., described in the Object Dictionary) are selected. For example, in the following command, all the defined objects are selected for use by the ZOMLIST service:

ZOMList +p d

In the next example, all objects that are not defined are selected:

ZOMList +p d!

Operating System Requirements

Zim IDE may require changes in the configuration of the client and/or the server machines to connect to databases properly. These changes may affect the virtual memory, the compatibility or security settings of these machines. In addition, there are specific requirements to run Zim IDE, according to the version of the Zim language installed installed on each machine:

Zim 7.12

On the server machine (host)

✓ the database;

✓ Zim Integrated Server;

✓ activated Zim Integrated Server license;

On the client machine (development)

✓ Zim IDE;

✓ Zim 7.12 ODBC driver;

✓ activated Zim 7.12 ODBC license;

Zim 9.00

On the server machine (host)

✓ the database;

✓ Zim Server;

✓ activated Zim Server license;

✓ activated Zim 9.00 ODBC license;

On the client machine (development)

✓ Zim IDE;

✓ Zim 9.00 ODBC driver;

Zim Server

Different operating systems require different configuration changes to run Zim 9.00 properly.

Please consult the following links for specific configuration options for your operating system.

 

Windows XP

Windows 2000/2003/2008

Windows Vista/Windows 7

 

For more information on how to configure and use Zim Server (Zim 9.00) or Zim Integrated Server (Zim 7.12), consult Getting Started.

Zim Object Uniqueness Conditions

In the Zim language, the children of an object are represented as having a dot (“.” ) between its name and the name of its parent. For instance, a push button whose name is pButton in the form fAddCustomer in the directory dCustomerRecord will be represented as  dCustomerRecord.fAddCustomer.pButton

The complete reference to the object needs to be unique in a database. In other words, form fields need to be unique within a form, forms need to be unique within a display and also within a directory.

 

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.

Logging in to a Database

The driver provides a login dialog under one of two conditions. The login appears if

  • the application using the driver passes it a blank user id or password

  • the user id or password variables are not defined in the registry

The User ID and Password passed to the driver from the application override those defined in the registry.

Using Per User Entity Sets

Even though per user entity sets are private and only seen by the user that created them, they can still be available to an ODBC Driver connection by means of the Dynamic Creation of a Data Source, which informs the work path that contains the per user entity sets. When the third party software connects to the corresponding Zim database, the per user entity sets are handled in the proper way as though they were local to this connection.

In order for the ODBC Driver connection to properly “see” the data in the per user entity sets, the third party software must be invoked within the Zim session that created the per user entity sets and their corresponding data.

Invalid results will be achieved if the ODBC Driver connection is established:

. before starting the Zim session that will create the data and the proper connection;

. before creating the data, but within the Zim session;

. after ending the Zim session that created the data and the connection.

 

en_CAEnglish