-
Notifications
You must be signed in to change notification settings - Fork 0
Getting data to and from fields
Have you noticed we did not declare any means to store or retrieve the values entered for each field? That's because it is also automatically handled for each map. The Map
class defines a property called Fields
that can reference any field defined in our map, the index of a field is the order in which it appears on the map itself, just like placeholders relate do field declarations. In our BookInfoMap
example, the title field is index 0, sort title is index 1, and so forth.
There are no naming associated with the fields but it is easy to be done so you don't lose track of each field you might be altering. Here I suggest two techniques you can use in your own maps. The first (and simplest) is to define constants on your map class with the index of each field that is important to you. For our example you would have something like:
private const int TITLE = 0;
private const int SORT_TITLE = 1;
In our BookInfoMap
example, notice the description field takes actually 6 fields (indices 14 to 19) and denotes a limitation of our toolkit (which would also be a limitation of mainframe applications built with CSP, as far as I know): if you need a field to contain more data than could fit in a single line, you will have to handle it using multiple fields and handle the connections between them yourself. This leads to our second technique in handling fields: build custom properties for each.
public string? Title {
get => Fields[0].Value;
set => Fields[0].Value = value;
}
Either way you set the Value
property of a field will get that value immediately on the screen. Thus, using this strategy, you can work out how to best combine two or more fields to provide the value of a single property for your map, just like on the description field.
Another thing that must be taken in consideration regarding fields is that all values stored by the map are strings thus any conversion to a format that would best suit your application is up to you. For example, the set of fields for the book format could be converted to a single property (using an enum
as value type) like this:
public BookFormat Format {
get => $"{Fields[10].Value}{Fields[11].Value}{Fields[12].Value}".ToUpper() switch {
"X " => BookFormat.Paperback,
" X " => BookFormat.Hardcover,
" X" => BookFormat.Ebook,
_ => throw new InvalidDataException(),
};
set {
if ((int) value is not >= 0 or not <= 2) {
throw new ArgumentOutOfRangeException();
}
Fields[10 + ((int) value)].Value = 'X'
}
}
You may choose other means to ease handling this and other sources of data, only remember to sanitise it so you don't get unexpected results from changing your application.