Information in this help file pertains to: eventedit.dat

Using ASCII front end mode causes the software to ignore its own internal event database and read events directly from an ASCII file.

The options needed to initiate this feature are found in the event customization file under the [FRONTEND_MODE] section. These options are explained in detail below:

Format of ASCII front end mode data file

The format of the ASCII front end data file is identical to the import file format except the first line of the file must contain the current version of the file and the number of events in the file. The first line should look something like this:

    version[delim]nrows

    version     the current version of the file (4[delim]0[delim]2)
    nrows       the number of events in the file (excluding field header row)
    [delim]     the field delimiter (one of semi-colon, comma or tab) you choose for the file

For example, a file, delimited with semi-colon containing 10 events would have these first two lines:

    4;0;2;10
    "subject";"date"...

The second line of the file must contain field names as described in the import file format help page. Each remaining line in the file ('nrows' of them) must contain the actual event data. Include each event on one and only one line. Do not include blank lines. Do not include comment lines.

Field delimiter

You may use any one of three possible field delimiters to separate the fields of your data: a tab, a comma or a semi-colon. The delimiter for the entire file is determined by the delimiter found in the first line of the file as follows:

    If a tab is found anywhere in the first line then
        delimiter is a tab
    else if a semicolon is found anywhere in the line then
        delimiter is a semicolon
    else if a comma is found anywhere in the line then
        delimiter is a comma
    else
        delimiter is a tab

You need not specify a delimiter other than by delimiting the first line of the file.

Why would one use this feature

Many of our clients have other processes or programs on their website that generate scheduling information (for example a doctor's office may have an online billing, patient information and scheduling system). In some cases this other process displays the scheduling information poorly.

With this feature you may keep your existing scheduling system but use our software to display the results. You will need to modify the existing system to export its data into our format and place the file in the correct location on your server (in each calendar's data folder).

For example, one of our users modified an existing application so that each time an event was added, edited or deleted to that application a file called events.txt was written to ./data/calweb. Our program simply read the file and displayed its contents. In this way the display of the data is as fresh as the contents of the events.txt file (which were always current). Our software was acting as an ASCII front end to the existing application.

You must create a separate events.txt file for each calendar. The modifications mentioned above to the eventedit.dat file must be made in each calendar folder.

Performance

The ASCII file is read and parsed each time the calendar is displayed. For this reason this mode of operation is slower than the native proprietary mode. If there are more than three to four hundred events in the ascii file the performance of the program may be too slow to be effective. There are a number of things you may do to alleviate this problem: