The xaccTransRollbackEdit() part of the Begin/Commit edit-block rewrite.
Broken out just for clarity.
Note: There's one piece that I didn't change that I think is conceptually
awkward. It has to do with how/when we would discover that another
user has deleted the transaction we'r
Splits can now keep track of their own rollback state.
The Split <-> Account and Split <-> Transaction relationships are now
treated as properties of the Split. In terms of the BeginEdit/CommitEdit
block, Splits are subordinate to Transactions. There is no public
BeginEdit/Commit
Remove xaccAccountRemoveSplit, and xaccAccountInsertSplit.
(Actually, xaccAccountInsertSplit is #def'd to xaccSplitSetAccount().)
Accounts no longer manage their Split lists. The Account split lists
should only ever be modified from within xaccTransCommitEdit(). This
simplifies som
A good bit of notes about how the Transaction Begin/Commit
edit-blocks should work, and why.
Converts the very important xaccTransCommitEdit function to use the
qof_commit_edit_part2() function instead of something that is 90%
similar.
Transactions have a Split list that keeps
Remove some testing of an engine API that has been removed.
The engine used to have functions that made it possible to orphan a Split.
As this is no longer possible, we can't test anymore.
Incidental:
Fix three or four small leaks in the test functions.
Allow test-period to
This patch series is a reimplementation of transactional semantics for
Transactions. There are plenty of notes for the individual patches so as a
summary I'll try to highlight what I think is the most important change:
There's an important but subtle different between an object's properties an
Bits to let the register see the in-progress Transaction edit.
---
src/register/ledger-core/split-register-load.c |2 ++
1 files changed, 2 insertions(+)
Index: trunk/src/register/ledger-core/split-register-load.c
===
--- trun
Move one data-validation function from Scrub.c into Transaction.c
One simplification in xaccTransScrubImbalance() to always find the root
AccountGroup from the Transaction's book.
---
src/engine/Scrub.c | 94 ++---
1 files changed, 19 inse
Remove two slightly different definitions of
gnc:transaction-map-splits, both unused.
Remove g-wrapped versions of functions being removed:
gnc:account-fix-split-date-order,
gnc:trans-fix-split-date-order
---
src/engine/engine-utilities.scm |9 -
src
On Wednesday 01 March 2006 3:19 pm, Derek Atkins wrote:
> Christian Stimming <[EMAIL PROTECTED]> writes:
> > Actually I do. (should we have a vote on this one? :) And as a reader of
> > someone else's code I would actually prefer very much to not have macros
> > affect the control flow of the calli
Applied. Thanks a lot.
Am Montag, 27. Februar 2006 22:54 schrieb Didier Vidal:
> Here is my weekly update of the fr.po
> 2646 translated messages, 657 fuzzy translations, 428 untranslated
> messages.
>
> Regards,
>
> Didier.
___
gnucash-devel mailing lis
Sorry.
You might want to ask the report author.. (his email is in the
report source file). This was added to CVS HEAD a long time
ago.
-derek
Quoting Didier Vidal <[EMAIL PROTECTED]>:
Nobody knows ?
Didier.
Didier Vidal wrote:
Hello,
I have a problem for translating the 'merchandising'
Nobody knows ?
Didier.
Didier Vidal wrote:
Hello,
I have a problem for translating the 'merchandising' options of the
trial balance report.
This option panel enables to select accounts for 'gross adjusting',
but I haven't been able to find a definition of 'gross adjusting' (and
how it diff
Applied. Thanks.
-derek
Quoting Andrew Sackville-West <[EMAIL PROTECTED]>:
trivial patch to use html-transaction-anchor in transaction report.
take it or leave it as you desire ;)
A
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information
trivial patch to use html-transaction-anchor in transaction report.
take it or leave it as you desire ;)
A
Index: src/report/standard-reports/transaction.scm
===
--- src/report/standard-reports/transaction.scm (revision 13367)
+++ sr
Christian Stimming <[EMAIL PROTECTED]> writes:
> Actually I do. (should we have a vote on this one? :) And as a reader of
> someone else's code I would actually prefer very much to not have macros
> affect the control flow of the calling function. So in this discussion I
> indeed agree with Chr
Derek Atkins schrieb:
BTW, this is only slightly less horrible than macros that use local
variables from their calling context. The general rule is, "If it
looks like a function, it sure better behave like a function." (*)
See, I never make the assumption that Macro == Function, even
if it l
17 matches
Mail list logo