Node:Internal structure of kort program, Next:List of thingies, Previous:Database structure, Up:Top

Internal structure of kort program

Chaos reigns within.
Reflect, repent, and reboot.
Order shall return.1

• Phile record.h contains the record_t data structure. This holds about every valuable piece of data about interpreting data records.
• kortparser.y is yacc/bison source code that is used to parse the Application definition file syntax and when finding something valuable, this part usually calls something from
• record.c is collection of functions that for most part are used to construct an array of record_t data structures that does define the application in hand. A few functions like editrecord or date-related functions are called at runtime in other situations than reading the application definition file.
• kortelements.lex contains the lex interpretation rules for static strings and language elements used in Application definition file syntax.
• main.c is the part where execution begins. Initialization stuff for most part.
• db.c is where about all database interaction should be done. Functions of most interest are of course save_record_to_db and fetch_record_from_db but there is also a lot of stuff that is used to make values for record identifiers and locking records.
• kort_tcl.c contains parts needed for calling TCL interpreter.
• net.c contains UDP/IP -related stuff, but message-sending functions are also found from db.c.
• static_strings.c contains initialization of (error)messages.
• util.c is a collection of misc functions, one of the more interesting is function trimbothways that is used to mangle every value going to database and that removes whitespace from beginning and end of every string value. Do not try to save value "whitespace and something else" as only "something else" will be left as you retrieve your record.
• visualization.c contains parts that deal with curses. There is pieces that draw the form for each record and pieces that give meaning to user input. Large parts of this file are stolen from doc/ncurses-devel-5.2/test/ncurses.c of ncurses 5.2 distribution.

• There may be 255 fields in each record, definitely enough as there may not be hidden fields so programmer must find space from terminal screen for each field, if she finds she does not, should he consult J. Preece et al.; HCI; ISBN 0-201-62769-82 for details about fitting many fields to one screenful.
• nfields and nlabels contain number of fields and labels present for each record .. record_t is present once for each record. Many members of the record_t structure are for each field, like field_x that is defined as int field_x[256] and it means that in field_x[0] there will be the x coordinate for first field that is given for a record in application definition file.
• should tablename point to NULL would recordname be assumed to be a record that will not be saved to DB.
• njoining_records is number of records that have this record as their subrecords.
• allowed_values_table_for_field and allowed_values_column_for_field are used to specify at runtime the ALLOWED_VALUES directive from application definition file. Their NULL-pointage is checked at least from file visualization.c when navigating out from field.
• func_key_actions specify the thing that is done when Fx is hit.
• func_key_recordnamepointers[x] should point to non-NULL when func_key_actions[x]==act_selectrecord as it causes another record to be selected.
• func_key_labels are the labels shown in the bottom of the screen. curses has different modes for these labels, currently kort uses mode that displays 8 labels. There is usually mode function keys, currently kort has support for 12 function keys so F9-F12 will not have any label displayed but they may have a function anyway.
• askfirst is indication whether function key action should be confirmed by the user before action is taken.
• record_id is set at runtime. It is the given surrogate value for record that is saved to associated data table column recid. This number is used to tell which record is which record. As there is one record_t in memory of kort at time, this number remains the same when user saves record content and changes (i.e. a new surrogate is invented) when user changes record as new.
• record_id_master is record_id of the record that is this parent of this record.
• nsubkeys is the number of records that have this record as their parent.
• subkeylist and subkeyindex are kind of historic relics, at some point it might have been possible to do "next record" and "prev record" operations for subrecord of a record and these variables might have been used for that.
• Structure members named tclcode_XXX point to tcl code that may be given to TCL interpreter at point or another. Some of them relate to record, some to function key and some to record field.
• dateformat_of_field is pointer to structure that contains information about parsing of date formats. In dateformatspec_t value of hh_pos is -1 if hour-part is not present is date format in question and if it is, then value of hh_pos is the position of number presenting hour in the string that contains said date in human readable form. Example is that if date format is "dd.mm.yyyy hh:mi" then hh_pos is 12 as hour begins from character position 12 at this string.

Compiling kort

Kort is for most part done in C. "gcc -Wall" doesn't produce serious complaints so in current incarnation the syntax of kort might conform to ansi C somewhat. Parser is written in yacc+lex so you'll need those; actually bison+flex was used but syntax should be the same. Of course thingies that kort tries to glue together must be present. At least one version combination that is known to compile is this:

• gcc-2.96, the infamous redhat release :)
• glibc-2.2.4
• mysql-3.23.41
• tcl-8.3.3
• ncurses-5.2

#ifdef LINUX_WITH_GLIBC21_OR_EARLIER
typedef unsigned long in_addr_t  ;
#endif

Footnotes

1. Who would not love Suzie Wagner?

2. Kicks some serious ass.