Crunch CRiSP File Editor 6 - Manual (Page 80)

Page 80
support these pipes. Windows/32 named pipes are more like TCP connection which allow
two tasks on different machines to communicate.
PTYs(pg. 84). A PTY, or pseudo-teletype, is the mechanism used by terminal emulators under Unix and
X-Windows, to allow the user to have separate xterm windows. Some programs can be
communicated to via pty's more easily than using any other IPC mechanism. For example,
the vi editor under Unix has no IPC support in it. But you could create a PTY running vi
and send keystrokes to the task.
DDE(pg. 85). DDE (Dynamic Data Exchange) is a mechanism only available on the Windows platform.
DDE is a special mechanism for interprocess communication which is limited to
communicating between tasks on the same machine in an unreliable manager. (Unreliable
means that there is no guarantee that a DDE operation will be successful; e.g. running out
of resources can cause an operation to fail).
DDE has mostly been supplanted by much higher level protocols, such as OLE. However
DDE is most commonly used in SETUP applications for Windows applications to talk to
the Program Manager or Explorer to create program groups for installed applications.
DDE can be used, for instance, also to communicate with the WEB browsers (such as
Netscape's Navigator or Microsoft's Internet Explorer product), e.g. to tell it to fetch
particular pages.
Signals(pg. 86). Under the Unix operating system, CRiSP supports signal notification using the SIGUSR1
and SIGUSR2 signals. This allows a macro to be notified of some external event.
CRiSP provides access to these IPC mechanisms using a generic mechanism. Macros can be written to
largely ignore the distinction between any of these IPC types.
{button See Also, ALink(ipc,,,)}
IPC Primitives
CRiSP provides the following primitives for accessing the IPC mechanism:
ipc_create Used to create a connection.
ipc_close Closes a connection.
ipc_read Read data from a connection.
ipc_write Write data to a connection.
ipc_accept Accept an incoming connection request from a remote application.
ipc_status Retrieve miscellaneous status about a connection.
ipc_register Register a callback which can be called when data is available to be read, written, or on
an exception.
ipc_unregister Cancel a callback.
register_macro A generic function used to register CRiSP callbacks on certain conditions. One of the
important conditions in the area of IPC is the REG_SIGNAL condition.
These primitives are loosely similar to the underlying socket library available on most systems. The
primitives provide sufficient generality to write non-blocking macro applications that can act transparently
within the CRiSP editing environment.
These primitives are fully covered in the CRiSP Macro Primitives Guide.
{button See Also, ALink(ipc,,,)}
IPC Callbacks
The way to successfully use the IPC primitives in a macro is based on callback macros. You can do things
synchronously in line, but doing so can cause the user interface to hang whilst waiting to send or receive
remote data.
When using the TCP/UDP protocols, you may face long delays in making a connection to a remote host. All
kinds of things can cause this delay - propagation delays, DNS name resolution, and machines which are
down.