Cannot find text or value inside a split

David Carlson carlson.dl at sbcglobal.net
Sun Feb 17 14:15:18 EST 2013


On 2/16/2013 3:38 PM, Colin Law wrote:
> On 16 February 2013 16:15, John Ralls <jralls at ceridwen.us> wrote:
>> On Feb 16, 2013, at 12:21 AM, Colin Law <clanlaw at googlemail.com> wrote:
>>
>>> On 16 February 2013 00:58, DonM <dm413-gc at intielectronics.com> wrote:
>>>> ...
>>>> The register page displays ALL the splits for a transaction -- for example
>>>> when looking at my checking account it shows not only the split that credits
>>>> the register account, but also shows all the splits that debit the expense
>>>> accounts. When I look at any single account I am looking at more than just
>>>> the splits that affect that account, I am looking at all the related splits.
>>> I am guessing that is because it only shows the splits for one
>>> transaction at a time.  The problem is that it needs to search all the
>>> splits for all the transactions at once and that is not available when
>>> the search is performed.
>>>
>>>> That leads to another thought -- if the data can be displayed in the
>>>> register page, I would think it would be accessible from the search dialog
>>>> as well. Both of them start knowing only that they are supposed to display
>>>> information about a specific account -- the register displays all the
>>>> associated splits, but the find dialog does not.
>>>>
>>>> Why can't you replicate whatever logic is used to display the register? What
>>>> am I missing?
>>> The fact that the register only shows splits for one transaction at a time.
>> That's not correct. Select View>Transaction Journal to see all of the splits for all of the transactions. It's the default view for "Find" results windows.
>>
>> It's not that we can't replicate the logic, it's that the Find code *doesn't* replicate the logic, because the author wasn't thinking of the use case that we're discussing here.  Patches welcome.
> It was the fact that someone earlier in the thread (was it Derek?)
> suggested that it would be challenging to implement that made me
> assume it was a more fundamental problem.
>
> Colin
>
Going back to John's comment about patches being welcome... Now that the
transition to SVN is complete, is it any easier for somewhat savvy users
to take a more active but part time role somewhere in the development
process?  If so, how can we help?

David C


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xDC7C8BF3.asc
Type: application/pgp-keys
Size: 1729 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-user/attachments/20130217/74533a4f/attachment.bin>


More information about the gnucash-user mailing list