gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] layout managers


From: Ian Haywood
Subject: Re: [Gnumed-devel] layout managers
Date: Sun, 25 Jul 2004 22:40:56 +1000

On Sun, 25 Jul 2004 13:21:20 +0200
Karsten Hilbert <address@hidden> wrote:

> level. That much conformity I think we are entitled to
> enforce *evil grin*
Fair enough.

> > EVT_PAINT has two shortcomings compared to the current code.
> >     - widgets can't veto being uncovered. (Personally I don't see this as a 
> > problem, I can cope
> > with seeing blank fields if no patient is loaded.)
> a) the problem isn't the user coping with blank fields but
>    rather the widget code continually having to check for
>    patient existence unless we adopt the hard-and-fast rule
>    "if I am visible I DO have a patient"
As far as I understood, this was what Horst was talking about -- 
when EVT_PAINT is received, the widget reconciles business layer reality with 
its
display, whether that's no patient, new patient or new data from the backend.

> This is the main problem of the above scheme. Layout managers
> would need to call a method you_are_not_visible_anymore() upon
> switching to another widget. Which is IMO an acceptable thing.
I agree.

> > This isn't a factor if we move to the behaviour of Richard's client (where 
> > the demographics
> > screen comes to the fore automatically to display patient search results, 
> > instead of a popup result window) 
> This doesn't at all solve the issue at hand as far as I can
> see. How does it react to backend data changes related to the
> patient currently being displayed ? I mean, one could popup a
> window saying
It relates to the new_patient event only in that all other notebook widgets 
become hidden when this happens,
so they don't have to worry if they're visible (because they're not). I admit I 
was not thinking about other event types:
these backend data changes relating to the current patient are another kettle 
of fish.
To be honest, I've never truly understood this.
For instance, when the backend listener generates an event, the business layer 
must
respond first (if the GUI responds first, it will upload from old data in 
business layer cache)
How is this enforced? Presumably with two events: one listener -> backend, one 
backend -> GUI,
but I can't see this in the code anywhere. Can you explain?

More importantly, this all sounds like a very large amount of work for very 
little gain. At the end of the 
day, a patient can only be at one place at one time, and only one thing can 
happen to them at once.
(except in resus, I suppose, but then there is still only one person doing 
documentation) What am I missing?

Ian 
 




-- 
PGP public key E750652E at wwwkeys.pgp.net
9BF0 67B7 F84F F7EE 0C42  C063 28FC BC52 E750 652E

Attachment: pgpAnqJxZ3XUL.pgp
Description: PGP signature


reply via email to

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