This code affect more things than are immediately obvious:
Traditionally (using ACEDB) we could search in a column for features using the feature context as a featureset in the feature context mapped onto a Canvas column directly (1-1).
Now that the feature context has been organised as one set of features per featureset the search process has been changed slightly and although the user can select a column as before the code has to extract all the contained featuresets and search each one.
This involves a mod to the search code that implements a list of keys to search for. For example if you select the column Repeats there will be a search though Repeatmasker_LINE, Repeatmasker_SINE and a few others. If you try a wild card for the column the each one of these columns will be expanded in the same way. If you select a featureset then the search is restricted to that one only.
The style filter has also been removed as if performed the same function as choosing a featureset but due to the proliferation of styles with computer friendly names was not very usable.
This used a search with align, block, and column unspecified, and it was necessary to supply the column ID from the selected feature. This should not be a problem as the feature names are accession numbers and should be different in different columns.
Of main interest are: zmapWindowItemHash.c (for doing the search), zmapWindowSearch.c (for operating the search window), zmapWindowFeature.c (for the feature menu) zmapWindowDrawFeatues.c (for the column menu).
Both the context and canvas are organised as trees of data structures in the following hierarchy: Align, Block, Strand (canvas only), Featureset/Column, Features. There is a series of hash tables following a similar structure owned by the window and at each level the hash table contains entries for the next lower level. Note that although these hash tables can be searched they are implicitly unsorted.
One nuance that is worth noting is that the FToIHash is organised with each featureset split into strand and frame combinations and it is possible to select (eg) all reverse strand features in a set without accessing any others. This gives us a two-way mapping of featuresets in that several featuresets may be mapped into a single column and also each of these featuresets may be split into several columns according to strand and frame.
In zmapWindowItemHash.c there are two functions zMapWindowFtoIFindItemFull() which finds a single item via the FToIHash and takes a featureset as one of its arguments. By contrast zmapWindowFToIFindItemSetFull() takes a column id (and also an optional featureset id) and searches for a set of matching features, allowing for wildcards.