back to basics: live(li)ness?

[Chris Pressey]

On Thu, 13 Mar 2003 15:28:05 +0100
"Vlad Dumitrescu (EAW)" <Vlad.Dumitrescu@REDACTED> wrote:

> > On the other hand, if the data on the screen represents real live data
> > then of course it should change on the screen right when it changes in
> > the application -
> 
> Mmmm, I didn't mean that... I referred to typing in a textbox and
> halfways, all I wrote dissapears and is replaced by something else.
> 
> What I wanted to say is (in a different wording) that for example a
> textbox that the user can or must type in text should not be a direct
> view of the application's data. There should be only one possible source
> for changes in that box, either the user or the application (and in the
> latter case, the box should be read-only).
> 
> I think it should be common-sense, I think my explanation was clumsy.

Ah.  I think what you are saying isn't live(li)ness by my definition :)
I'm trying to follow what was put forth by Eric Merrit and Bob Smart
almost exactly a month ago.

Example: you want to print to "\\Printers\Laser017" so you select it in a
listbox.  As you are doing so the sysadmin takes that printer offline for
repairs.  If the GUI is live, the option disappears for you immediately.
In an ideal world it offers some obvious feedback (beep) and an
explanation as to why it happened, too.

So - you don't just need locks, you probably need a prioritization /
authority scheme, too (the sysadmin, who outranks you, can override your
selection.)

> regards,
> Vlad

-Chris