[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Re: popups on SOAP
From: |
Richard Terry |
Subject: |
Re: [Gnumed-devel] Re: popups on SOAP |
Date: |
Thu, 22 Jul 2004 15:42:00 +1000 |
User-agent: |
KMail/1.5.4 |
See comments below:
On Thu, 22 Jul 2004 03:32 pm, Ian Haywood wrote:
> 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?
Can you 'map' the control - ie if the mouse clicks anyway on the left area of
the control from character spot 0 to character spot n (ie you have defined a
column of the editor which will contain the prompts), then the cursor is not
allowed entry.
Note that with Pycrust they have defined non-editable areas of the screen
quite easily. Perhaps this control we should look at because the source code
should be quite obtainable
> 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
Richard