Re: [Gnumed-devel] update mechanism for gmGP_ use cases.

[Karsten Hilbert]

>    when the gmPatientSelector creates a new current patient object, the 
It shouldn't create one. There should only ever be one which
may change it's association with a particular patient in the
backend.

> I used gmDispatcher to send a patient_object_changed() signal , and got 
The gmCurrentPatient() will send that signal by itself. No
need to send more signals.

> the gmGP_  widgets to inherit from a patient
> holder class that listens for that signal;
Sounds OK to me.

> the signal is parameterized 
> with the new current patient object, so each
I would avoid that and make the gmPG_ objects reget
gmCurrentPatient() if needed.

> gmGP_ object can know when the model has changed, and can save unsaved 
> data in the old patient model,
A signal is sent just before actually changing the patient inside
gmCurrentPatient() upon receiving which saving state can be
done.

> and with the new patient model, update 
> lists displays, and clear edit areas as needed. 
Another signal is sent when the active patient has actually
changed.

Other than that this sounds reasonable.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346