Assuming that is right, I wonder if the best way to extend SQL syntax would be with an extra function SelectionKeysUpdate(<table>, <keys>, <add>) and variant SelectionKeysUpdateWindow(<table>, <windowName>, <layerName>, <keys>, <add>) where <table> would be the target table, <keys> a table of mfd_id values, and <add> a Boolean flag. If the <add> flag were true, the table of mfd_id values would be added to the SelectionKeys table for the target table. If false, they would be removed. The effect on the selection would be governed (as usual) by the state of the SelectionIsInverted (or SelectionIsInvertedWindow) flag. If false, then adding ids would select the given records, and removing ids would deselect records. If true, the reverse. To add to the selection regardless of the state of SelectionIsInverted, we would use SelectKeysUpdate(<table>, <keys>, TRUE XOR SelectionIsInverted(<table>)) and to subtract SelectKeysUpdate(<table>, <keys>, FALSE XOR SelectionIsInverted(<table>)) The table of mfd_id values to add/subtract as keys could be built e.g. by a SELECT, VALUES or TABLE statement, possibly using ValueSequence, possibly using a FUNCTION, possibly stored by a VALUE assignment. There is plenty of scope for Select templates making use of these functions, and writing them via the Edit Query button. (At present, the Edit Query button for Select templates produces SQL which does not adjust the selection, but only lists records. With new functions like those above, output SQL could exactly reproduce the template functions.)
|