gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Re: popups on SOAP


From: Ian Haywood
Subject: Re: [Gnumed-devel] Re: popups on SOAP
Date: Thu, 22 Jul 2004 15:32:29 +1000

On Thu, 22 Jul 2004 14:01:22 +1000
Richard Terry <address@hidden> wrote:
> I'm not sure how it works your end. Nothing would popup at all at first, then 
> I noticed if I  left a space after prescribe it would popup. 
There is a 300ms timeout on the popup. The idea is that if you keep typing 
after the 
keyword, the popup doesn't not appear.
> In the popup the 
> first two complete lines where flashing (ie the drug and dose headers), but 
> if I filled info into these lines the top two lines completely disappear.
????
I haven't seen this. Can anyone else report on this?

> With the popup referrals/scripts, I think the default behaviour of the <ESC> 
> kjey should be to remove the edit area but not save the content. If the ok 
> button is clicked the summary of the drug/referral etc, is placed back within 
> the plan line. This summary CANNOT BE EDITED  MANUALLY. If the user attempts 
> to do this, or say double clicks over this text then the popup for that 
> particular type is automatically invoked.

Coloured text can be protected from user editing, but not to an unlimited 
extent.
As Jim has pointed out, users can still select into header or summary text 
using the mouse and then partially delete the text, 
thus messing the whole thing up. I don't know how to stop or even detect users 
doing this, does anyone know of a way?
But as it requires some deliberation on the users part I'm not too worried for 
now. 

What's harder is embedding a reference in the summary to the data that was in 
the popup.
Options:
        1/ make summaries parseable so we can reconstruct the popup fields from 
the summary text. For coding this means
the code has to be in the summary, so "Pneumonia [N42.2]" for example, but 
that's proably what we want anyway. 
        2/ embed a key using a white-on-white style to a Python dictionary. 
It's important the user can't see it as
it would just be a random number.

Personally I prefer 1/ although it needs careful thought to strike the balance 
between parseability and readability.

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

Attachment: pgpfPwocFsTli.pgp
Description: PGP signature


reply via email to

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