This is the Catch-22 of relying on Filters during Reconciliation, and really applies to any situation where a Filter is used to isolate a group of Entries prior to adding to or changing them: When a visible Entry is changed so that it no longer matches the active Filter, it is inconsistent to allow it to remain visible when it no longer matches the active Filter. It is also inhumane to remove an Entry completely from view after it is created or changed, preventing a user from reviewing the change in the context of the Entry or Reconcile tables.
CheckBook originally worked around these potential issues by introducing a "lesser" evil: it would cancel the active Filter when new Entries were created or when existing Entries were changed. The active Filter would become General with no Filter data. That would match the visible Entries, and would keep the new or changed Entry in view.
Later, we received enough feedback to indicate there should at least be a preference so users could choose what they felt was the lesser of evils. So we set a new default - the active Filter would remain active after Entries were created or changed, but any Entries that did not match the active Filter would be hidden. It's inhumane, but it is consistent. The original behavior, where the active Filter is canceled and the new or changed Entry will be visible at all times, is still available. The preference is called "Cancel Filter When Adding Or Changing Entries", under the General tab in CheckBook's Preferences sheet.
We always had one compromise in CheckBook, however. To make Reconciliation easier, we drew a line between changing an Entry explicitly, in its Entry sheet, and setting the Resolved checkbox directly from the Entry or Reconcile tables. When a user enters the Entry sheet for any Entry and presses the OK button, CheckBook examines the preference for canceling the active Filter, and either cancels it or re-Filters the Account's Entries. But, when a user interacts with the Resolved checkbox for an Entry in either the Entry or Reconcile tables, CheckBook will not cancel the Filter and will not re-Filter the Account's Entries. It's inconsistent to leave Resolved or Unresolved Entries visible when they may contradict the active Filter, but there is some distinction between the two ways the data can be changed - changing it in the tables seems somewhat less "final" than going through an actual change/Entry sheet session.
We appreciate that, in this case, CheckBook is less than ideal for how you would like to use it. We're open to feedback on how to make it better, but we would like the interface to remain consistent with the visible Entries, and we need to avoid the confines of an ultra-concrete Reconciliation method (ie. forcing Entries into clearly defined Reconcilation sessions, instead of simply relying on the Resolved checkbox).
_________________ Keith GugliottoPrimordial Sea CaptainSplasm Software https://www.splasm.com
|