[Top][All Lists]
[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
pgpAnqJxZ3XUL.pgp
Description: PGP signature
- [Gnumed-devel] layout managers, Karsten Hilbert, 2004/07/24
- Re: [Gnumed-devel] layout managers, Ian Haywood, 2004/07/25
- Re: [Gnumed-devel] layout managers, Karsten Hilbert, 2004/07/25
- Re: [Gnumed-devel] layout managers, Karsten Hilbert, 2004/07/25
- Re: [Gnumed-devel] layout managers, Horst Herb, 2004/07/25
- Re: [Gnumed-devel] layout managers, Karsten Hilbert, 2004/07/25
- Re: [Gnumed-devel] layout managers, Karsten Hilbert, 2004/07/25
- Re: [Gnumed-devel] layout managers, Karsten Hilbert, 2004/07/25