Okay, sorry, my last post may have been a bit ambiguous. Here's a better explanation of how TBLView 2 handles tables and modular tables...
TBLView 2 operates on a configuration file of its own (with syntax similar to FSO's tables and Windows' INI files). The file is set up in this format:
# tblview.cfg example
# Lines starting with a # are treated as comments by TBLView 2.
# This is just an example of what TBLView 2 can do.
# In this block, we define the name of the table that TBLView 2 can read.
# For this example, we will be using species.tbl.
#
# As indicated by the second line under [Table], species.tbl cannot be made
# into a modular table (according to FSO). In practice, it could be made
# modular, but the SCP folks have yet to code that...
#
# The third line under [Table] states whether or not this table has an $End
# of some kind. A fourth line, $EndMarkerText, would define what text is used
# for the end marker ("End" in most cases), but is ignored (and unnecessary) if
# $EndMarker is set to 0.
[Table]
$Name: species;
$CanBeModular: 0;
$EndMarker: 0;
# This block defines what a single table entry would look like.
# We used the example at http://www.hard-light.net/wiki/index.php/Species.tbl#Sample
# The syntax for each line after [TableEntry] is as follows:
#
# $Field "FieldName",fieldType[,optionalParameter];
#
# The optional parameter's input will vary, depending on the field type.
# In the case of xstr, we define whether or not an $end_multi_text is necessary.
#
# For optional fields, we also have $OptionalField (not present in this example),
# and for field modifiers (fields beginning with a +, with the exception of +nocreate)
# we have $ModifierField (also not present in this example).
#
# Finally, we have $AlwaysRequiredField (which, regardless of TBL or TBM, it will always
# be written to and read from the table).
[TableEntry]
$AlwaysRequiredField: "Entry",ignore;
$Field: "Name",xstr,0;
$Field: "Anim",string;
$Field: "AlwaysInTechRoom",integer;
$Field: "Description",xstr,1;
[EndTableEntry]
# Just for completeness, [EndTableEntry] and [EndTable] need to be explicitly
# declared (to make the parser's job easier).
[EndTable]
TBLView 2 will parse this configuration file and use it to determine what values can be acceptably used in each table. This way, if a new table is added (or new options for a table are added) with a new version of FSO, we simply have to release an update for this file rather than releasing an entirely new program.
What I was trying to say in my first post, Galemp, was that this is how TBLView 2 determines acceptable input values. This is not just for error checking, it's for the whole program.
You won't need to ever touch tblview.cfg unless you're updating it. Doing so may cause TBLView 2 to generate invalid tables.
And as for whether or not we'll have dropdown menus or checkboxes for flags, I may just keep it a simple editable value where you directly type in the flags rather than using a checkbox or a dropdown menu. Java's Swing interface libraries aren't the most intuitive in the world, so a dropdown or checkbox would likely require me to re-invent the wheel just to get it working.
