Crunch CRiSP File Editor 6 - Manual (Page 85)

Page 85
zero bytes, then the other end of the pipe has most likely terminated. Alternatively you may use the
ipc_register() callback to register notification on the death of a process.
{button See Also, ALink(ipc,,,)}
DDE Communications
DDE is a special type of IPC available only on the Windows platform. DDE is a simple programming
language based IPC mechanism, meaning that to implement all aspects of DDE requires low level access to
a programming language such as C, or C++. CRiSP supports a sub-set of DDE sufficient to enable CRiSP
macros to interoperate with other applications on the system. For example, you can talk to CRiSP from an
Excel spreadsheet and write macros which can be called directly.
DDEProgram Manager
DDE is most commonly used by installation SETUP.EXE programs to ask the Program Manager (on
Windows/95 and above, the Explorer) to create program folders and icons.
The semantics of a DDE conversation are usually very different from that of any of the other IPC
mechanisms. It probably has more similarity with UDP than with the connection oriented services described
in this document. A DDE conversation is transactional: a client application requests some service or data
from a server application, usually in a one-off operation. There is not necessarily a permanent connection to
a server.
For intimate details of DDE and its internals, you are referred to the official documentation available from
most compiler vendors.
CRiSP allows you to write macros which can talk to DDE servers (in which case CRiSP is the client), or to
create a DDE server which can receive requests from other applications. A typical client operation would be
to send a message to a WEB browser to display a page. Server side operation is useful when you want
CRiSP to be notified by some other task of an event, e.g. receive a command to load a file for editing.
Server Side operation
In order to create a DDE server, you need to create an IPC connection using the IPC_DDE method, as
follows:
Server:DDE
ipc_create(IPC_DDE | IPC_SERVER, "service:topic");
If the operation is successful, then a new IPC id is returned (an integer value) which can be used by the
other IPC functions. In order to receive client requests you will need to use the ipc_register function.
create_server(string service, string topic)
{ int ipc_id;
ipc_id = ipc_create(IPC_DDE | IPC_SERVER,
service + ":" + "topic");
ipc_register(ipc_id, IPC_TRIGGER_READ,
"dde_read_callback " + ipc_id);
}
void
dde_read_callback(int ipc_id)
{ stringcmd;
cmd = ipc_read(ipc_id);
message("Command: %s", cmd);
}
The service and topic name should be set to something suitable for your application. E.g. the CRiSP DDE
server macro (see below) uses "CRiSP" as the service name and "command" as the topic name. Any
application wanting to talk to CRiSP has to use these names.
When a client application sends a message to CRiSP, the registered callback routine will be called and the
string can be read using the ipc_read primitive. CRiSP buffers up commands, although it is best to avoid
sending commands longer than 512 bytes otherwise you may find the ipc_read() primitive returning the
command string split up, with the first read returning the first 512 bytes, and subsequent reads returning
each successive 512 byte fragment until the last fragment is read.