On Fri, 21 Apr 2000, Dave Peticolas wrote:
> > Bryan Larsen <[EMAIL PROTECTED]> writes:
> > > 2. Transactions can appear more than once. That seems pretty durn wacky.
> >
> > Dave: what did we decide about this? Is it a problem with the Split**
> > I am generating, or a natural side effect of the way the register
> > works? I remember that discussion about rebalancing multisplit
> > transactions being tied up with this somehow but the details escape
> > me.
It took me a while to figure out, when doing the Transaction 2 report, whether
to work with a list of Split*'s or a list of Transaction*'s. Split*'s was the
right answer, but a Split is really something that should not exist on its own
-- the transaction is really the primary element.
>
> We haven't really solved this problem in general. However,
> for the find functionality, assuming we are searching for
> transactions and not splits, you can get rid of this by
> not adding splits which have a peer split that have already
> been added.
>
> But then 'all register' operations may not work the way you
> would expect. I think we are bumping up against the limits
> of the current register model. We probably need to sit down
> and come up with a generalization.
>
I've run up against the exact same problem in the "transactions 2" report. I
haven't done anything about it, but it was my opinion that duplicates should
only be removed if:
1) in a multi-line report format, and
2) are in the same subsection.
the find register does not have subsections. Since the user is always editing
complete transactions, it is my belief that you should always remove
duplicates, whether in a multi-line display or not.
Bryan
--
-------------
Bryan Larsen, Senior Software Engineer & fall guy
Phone: 306 664 2087 x29. Fax: 306 664 4446
Analog Design Automation: Analog Circuit Synthesis? Problem Solved.
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
