gnumed-bugs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-bugs] Sufferable bug, billing


From: Karsten Hilbert
Subject: Re: [Gnumed-bugs] Sufferable bug, billing
Date: Wed, 2 Oct 2013 10:06:08 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, Oct 01, 2013 at 08:52:41PM +0000, Jim Busser wrote:

> > Ne'ertheless I have now made the phrasewheel empty out the
> > amount field should the bill item field be modified.
> 
> Thanks, but maybe it is I who is unclear. Where (above) you
> explain "This" is not a search field, are you referring to
> the "item" field or the "amount" field?

The "item" field. A (traditional) search field is where
one enters a search term and hits/clicks something to
initiate the search. This is not the case. The phrase-
wheel is a selection or input (depending on configuration)
field with suggestions.

> What I was observing was the case where
> 
> - I have inputted a value into (let's call it "item 1") into "item"
> 
> - an auto-search occurs … here I am not sure whether you
> are referring to auto-searching for a match on "item 1"

yes, it auto-searches for suggestions/completions

>  or a corresponding (related) financial amount

no

> but in any event, provided that what I entered into "item 1" is an
> existing item with a corresponding, related financial amount,
> that amount displays automatically.

It does not. It only gets displayed once you *select*
(one of) the suggestions.

In case there's only one match it might *seem* to get
auto-displayed when tabbing away from the field but,
technically, that's the phrasewheel auto-selecting
the only match for you given that you entered an
unambigous string. *That* will invoke the displaying
of the related amount, not the entering itself.

> - at this point, without my either committing or cancelling
> the transaction, I recognize that I had inputted the wrong
> item code, and I alter the value of "item 1" to be "item
> 2" and I then I then hit return, and observe no change in the
> "suggested" amount despite that "item 2" is likewise
> an existing value with a related "suggested"
> amount already defined in the database.

I understand. The enter/return will take you to the
next field, right ?  This had been suggested by Richard
back in the days to make enter/return act like tab.

At any rate, yes, this seems counter-intuitive. It
comes about like this:

When the first item is entered the amount is
set from the database. The amount can be adjusted
manually, too, however. Hence GNUmed only auto-sets
the amount when the amount field is empty. Which
isn't the case anymore after it had been set from
the first item.

However, editing the item seems to suggest the
user wants to enter another billable item.
Hence it makes sense to empty out the amount
upon editing. After which auto-setting the
amount should work just like in the first case.

> Thus I was imagining this a sign of a problem, because
> there *does* exist, in my database for item 2, a reference
> amount, and I could not understand why the same procedure as
> caused "item 1" to cause the "reference amount 1" to
> be displayed would not, upon the user altering the value
> of "item 1" into "item 2", cause a new lookup.

Well, it WAS the same procedure and it was the same
code that ran but code can take into account environmental
conditions and do different things based on that. And
it can be less than smart enough.

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346



reply via email to

[Prev in Thread] Current Thread [Next in Thread]