Board index » delphi » Generic read-only behavior

Generic read-only behavior


2003-06-25 04:14:37 AM
delphi114
I have an application that displays a template (consisting of many
different types of components), used to create user accounts. An
administrator has the ability to delegate permissions to other users of
the application to edit or only to view these templates.
A user who has only permissions to view a template will be able to see
all information on any of the components, interact with the component
(such as scroll down through a StringGrid), and mouseover the component
(some of them have dynamically generated Hints that need to be
accessible) - but *not* actually change the content of the component: no
editing of the text in an Edit field, no changing the ItemIndex in a
ComboBox, etc.
My question is this: how can I accomplish this read-only behavior in the
most elegant manner? I have considered so far:
* "Screening" the components by placing a transparent Panel (JvPanel) on
top of them. The components can be seen, but cannot be interacted with at
all. This is fairly elegant, but not a complete solution.
* Looping through all of the components and running an "is" comparison
against all of the possible types of components I have, and then handling
each type of component. This doesn't feel or look very elegant, though,
and in some cases does not get me the behavior I want, anyhow: for a
CheckBox, I can only toggle Enabled, which gives me the undesired grayed-
out effect (also making it impossible to distinguish a grayed-check).
* What I am toying with now is swapping out WndProcs or otherwise
intercepting particular messages so that some get through (mouseover, for
instance), but others do not (entering the field, sending keystrokes to
the field). This is a bit more low-level than I would prefer to be working
at, though.
I'm wondering if anyone has had a similar challenge or has suggestions.
What I would like most, of course, is an abstract, generic method for any
type of TControl (or even just most of them) that allows the user to
look, but not touch - that is probably too much to hope for, though.
Thanks in advance.
David Frauzel
 
 

Re:Generic read-only behavior

On 24 Jun 2003, David Frauzel <net.weathersong@nemo>writes:
Quote
My question is this: how can I accomplish this read-only behavior in the
most elegant manner?
Why are you fighting the windows standard? A greyed out edit box or check
box let's the user know they can not edit the value. If it is black they're
going to get frustrated.
--
-Mike (TeamB)
 

Re:Generic read-only behavior

"Mike Williams (TeamB)" <XXXX@XXXXX.COM>wrote in
Quote
On 24 Jun 2003, David Frauzel <net.weathersong@nemo>writes:

>My question is this: how can I accomplish this read-only behavior in
>the most elegant manner?

Why are you fighting the windows standard? A greyed out edit box or
check box let's the user know they can not edit the value. If it's
black they're going to get frustrated.

Questioning the Windows standard aside... ;)
For one, the template uses visual feedback to indicate certain states. The
templates I spoke of are hierarchical - a child template can inherit data
from a parent template. Inherited data (in an Edit field, for example)
appears grey. There's also the grayed checkboxes I mentioned. A grayed
checkbox is inheriting its value (the inherited value is checked), whereas
a "solid" check is a value of True on this template specifically.
Those are somewhat trivial aspects, though I would like to preserve them if
possible. More importantly, though, a disabled component does not receive
an OnMouseEnter event, which is fairly critical, to display the dynamic
Hints.
 

Re:Generic read-only behavior

"David Frauzel" <net.weathersong@nemo>writes
Quote
>My question is this: how can I accomplish this read-only behavior in
>the most elegant manner? I have considered so far:

I *think* I may have found a solution.
<snip>
Quote
The only question is... how reliable is this method?
<too lazy to test this>
Have you verified that it prevents edits, for instance, from showing their
default pop-up menus?
--
Regards,
Chris Luck.
 

Re:Generic read-only behavior

Quote
"David Frauzel" <net.weathersong@nemo>writes
news:XXXX@XXXXX.COM...
>The only question is... how reliable is this method?
I meant to add that the ploy will only prevent mouse/keyboard interaction.
If it is a significant issue for you then remember that programmatic tampering
is still possible.
--
Regards,
Chris Luck.
 

Re:Generic read-only behavior

"Chris Luck" <XXXX@XXXXX.COM>writes
Quote
<too lazy to test this>
Have you verified that it prevents edits, for instance, from showing their
default pop-up menus?
Having got over my inertia I find my hunch was well founded - it does not
disable popup menu action. That can be got around by adding an empty popup
menu to the form and assigning it to all controls that have a built-in (or
other) popup. This rather detracts from the simplicity of the idea (shame).
My other concern is that the focus is being changed in the middle of a
focus-change which can lead to unexpected/unstable behaviour. In your
situation, where you don't want any control to have focus, it may not be an
issue.
--
Regards,
Chris Luck.
 

Re:Generic read-only behavior

"Chris Luck" <XXXX@XXXXX.COM>wrote in
Quote
Having got over my inertia I find my hunch was well founded - it does
not disable popup menu action. That can be got around by adding an
empty popup menu to the form and assigning it to all controls that
have a built-in (or other) popup. This rather detracts from the
simplicity of the idea (shame). My other concern is that the focus is
being changed in the middle of a focus-change which can lead to
unexpected/unstable behaviour. In your situation, where you don't
want any control to have focus, it may not be an issue.
As it happens, I did already have a popup assigned to the form, which
"covered" the default pop-up; but I was suspicious of the same thing.
Because of the nature of the application, every control whose input is
relevant to the template has an OnChange event assigned to it as well. (I
know, I am coming close to trying to reinvent data-aware components.) I
simply made another check for permissions in that event, and prevent the
change from taking effect (in the template itself), then "revert" the
displayed template (after displaying a warning to the user).
It's a compounding problem, and I am approaching that dangerous territory of
trying to outsmart the user - but again, the worst that will happen is an
AV when the file cannot be saved. I am even putting some safeguards into
this process, a "TryFileWrite" function that wraps up a simple
TMemoryStream LoadFromFile/SaveToFile in a try..except to determine if a
file can actually be written to.