[Top][All Lists]

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

Re: [Gnumed-devel] another icon request/proposal

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] another icon request/proposal
Date: Fri, 4 Apr 2003 12:13:09 +0200
User-agent: Mutt/


I am extremely pleased to say that my current search widget
almost to the letter works like you describe :-))

The icon thingie is a different matter as I'll explain in the
next mail.

> NOTE::        
> In terms of functionality this is how I beleive the find patient wigit should 
> behave:
> -at bootup there is nothing in the wigit.
Yes. Right now if no active patient is selected - which SHOULD
only happen at startup - it will display "no active patient".
This is so people know what this field might be for without
requiring a label on it.

> -when the user clicks on the wigit and enters text the search is triggered by 
> one and one way only - hitting the enter key
Exactly. Works like that now.

> (+if desired a user defined function key),
That's a possibility. I put it in the notes.

> but certainly NOT any other events such as lost focus.
Absolutely not ! It does NOT work that way even now. What it
DOES upon loosing focus is to delete the currently typed
search term and redisplay the currently active patient - NOT
any other patient the search term might match !

> -if a single patient is found then their entire name and address is placed in 
> the box/combo (see png below)
Yes. If only one single patient matches the search term it is
placed in the box immediately without further user
intervention. The box displays "lastname, firstname", the
adjacent box displays "age", the next one "allergies". Various
other parts of the program are updated such as the title bar of
the main frame virtue of a signal

> -if multiple patients are found a MODAL box pops up with the list
Yes. That's how it works right now.

> (centred BTW in the middle of the gnumed main window and
Still needs to be done.

> large enough to display all the multiple names and addresses
Still needs to be done.

> Now, when the doctor has finished dealing with the patient the very act of 
> clicking on the wigit again (which at this point contains a name) triggers a 
> 'got focus' event. 
You mentioned this earlier, I will implement it since you
insist on it's goodness :-)  It IS in the notes already.

> This event checks that all information has been saved, forms printed etc 
> and if not prompts user to do that,
I personally think that

a) this is a bit prematurely because I can still decide to not
   change the active patient after all - this is in parts
   debatable and depends on the exact nature of the jobs to be
b) it is not the job of the patient search widget to take care
   of such things

But your point is certainly valid: Upon selecting another
patient to be active we need to make sure the previous one is
committed. And it DOES do this already.
gmTmpPatient.gmCurrentPatient is the pseudo-global Borg class
(think ConnectionPool) that handles the active patient. Upon
selecting a different patient it will explicitely commit the
previous one. Note the console printout ("committing patient
not implemented") - this stems from the call to "commit".

> then clears the wigit window and sets the 
> cursor at the start of the line.
OK, see above re got-focus.

> This works extremely well. I've done it for years in my program.
The latter is why I trust you on the former.

> As part of the got focus event for the patient search wigit - the patients 
> ID, name address etc is added to the drop down combo box which is the patient 
> search wigit. One would keep say, the last 10 (n=doctor defined) patients in 
> this list.
It already does this :-)   10 is hardcoded for now, though.
It is called up by ALT-P (Previous patients) or ALT-L (Last
patients) but perhaps I should just make that CURSOR-DOWN to
make it behave like a combo box.

> If in the middle of doing something for one patient, you need to swap to 
> another patient, then one can select from this dropdown list which then 
> replaces the internal datasets with data from the appropriate patient.
NO ! I happen to disagree with this one. No funny tricks with
temporarily selecting another patient. Use another client instance.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

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