Tab control: implementing selective access

Keisuke Miyako (6/6/14 7:11AM)
Kirk Brooks (6/6/14 9:24AM)
Jack Des Bouillons (6/6/14 11:03AM)
Tim Nevels (6/6/14 11:47AM)
Bill Weale (6/6/14 12:38PM)
Bill Weale (6/6/14 12:53PM)
Tim Nevels (6/6/14 9:05PM)
Bill Weale (6/10/14 2:29PM)
Bill Weale (6/10/14 3:07PM)

Keisuke Miyako (6/6/14 7:11 AM)

if you are using v13 or later then there is a form event called
?=A2?=82¨=C5ìon
Page
Change?=A2?=82¨=C2ù,

during which I suppose you could call OBJECT SET ENTERABLE or OBJECT
SET
ENABLED with the wild card character...

miyako

On 2014/06/04 23:38, "Bill Weale" <bill.weale@... wrote:

color><param>00000,0000,DDEE/param>II've implemented a scheme which
grants access to the pages of input forms
(using the tab control) based on users' group membership.

Now the client wants to add 'read only' to access/no access on a
page-by-page level within the input form. The form pages can contain
fields, variables, popups, etc. The record is loaded and read write.
Objects are mostly tabbable.

I can enable/disable an invisible button to block mouse-based user
actions, but is there and "easy" way to block tabbing and keyboard
input?

By "easy" I'm trying to avoid going to the object level to implement
this
type of control.

Thanks,

BIll
/color>
Kirk Brooks (6/6/14 9:24 AM)

<CAHY=XkvoBA1_VqXXZv-5vEivYEqKySAECktdbYezB8uysosmGA@mail.gmail.com>

On Fri, Jun 6, 2014 at 9:02 AM, Bill Weale <bill.weale@...
wrote:

color><param>00000,0000,DDEE/param>TThanks to all for the suggestions.
Seems like a surprising amount of work
(to me) to get it right, no matter what the approach.
/color>

?=80&atilde;Bill,
This is true. Creating an effective UI is no trivial task. Especially
if
you want to have a single form respond dynamically to varying states
(like
user permissions, editable/not-editable, etc.). 4D makes it easy to
get a
form on the screen very quickly and provides some really cool form
elements
that you can implement quickly. But that's not really a UI - it's just
database objects on a screen. A good UI leads to better user
experience,
impacts user productivity, impacts the quality of the data (fewer
errors on
a well thought out input/edit form), and so on. So, yeah it is kind of a
lot of work to get right but it's worth it. ?=80&atilde;

?=80&atilde;I can't help but also mention how much easier these sorts of
things
are to
manage if you adopt a scheme of having a single, project method to
manage
all your form objects. You can find several posts by me about this
here.
I'll just say it makes managing the type of forms you describe so much
easier and rational. ?=80&atilde;

--
Kirk Brooks
San Francisco, CA
==3D==3D==3D==3D==3D==3D==3D==3D==3D==3D==3D=
Jack Des Bouillons (6/6/14 11:03 AM)

I seem to recall that in the original post, reference was made to
enterable
fields AND variables...

The READ ONLY/LOAD RECORD will work for fields, but if there are
enterable
variables, or drop-downs, those would have to be handled individually.

Jack des Bouillons

On 6/6/14 9:47 AM, "Tim Nevels" <timnevels@... wrote:

color><param>00000,0000,DDEE/param>YYou said you wanted something very
simple to implement. I can't see anything
more simple than this.

Am I missing the point of what you are trying to accomplish?

Tim
/color>
Tim Nevels (6/6/14 11:47 AM)

On Jun 6, 2014, at 11:06 AM, Bill Weale wrote:

color><param>00000,0000,DDEE/param>TThanks to all for the suggestions.
Seems like a surprising amount of work (to me) to get it right, no
matter what the approach. Too many objects of too many types in too
many locations--specific form page, page 0 and inherited--to subdue
and restore both keyboard and mouse targets, visually as well as
really. Event handler and load/unload record have their own
complexity--and risk.

Having tried a few things, I'm wondering if others have had similar
thoughts:

If only there were a "physical" mask for keyboard events, able to be
sized/positioned, similar to what you can do with an invisible button
for mouse activity...

Objects can be grouped and their group can be named in the method
editor, but that group (of objects) can't be addressed by the
language...
/color>
Hi Bill,

Maybe you missed my post. I'll repeat it here.

You are in a form and have a record loaded in READ WRITE mode. You can
tab into fields and make changes to fields. ?Do this as a test.

Create a button on the form with this code:

READ ONLY([Table])
LOAD RECORD([Table])

Click the button. Now try to click in a field for the table and make
changes. You can't. This is an automatic feature of 4D to make all
fields on a form non-enterable if the record is locked or the table is
in READ ONLY mode.

You said you wanted something very simple to implement. I can't see
anything more simple than this.

Am I missing the point of what you are trying to accomplish?

Tim
Bill Weale (6/6/14 12:38 PM)

I agree in all respects.

If only the evolution of the under-the-hood capabilities hadn't been
accompanied by the devolution, relatively speaking, in
developer-friendly ways to implement them.

8-|

Bill

On Jun 6, 2014, at 12:24 PM, Kirk Brooks wrote:

color><param>00000,0000,DDEE/param>TThis is true. Creating an
effective UI is no trivial task. Especially if
you want to have a single form respond dynamically to varying states
(like
user permissions, editable/not-editable, etc.). 4D makes it easy to
get a
form on the screen very quickly and provides some really cool form
elements
that you can implement quickly. But that's not really a UI - it's just
database objects on a screen.
/color>
Bill Weale (6/6/14 12:53 PM)

Yes, I want it simple and I want it all!

8-)

You can still change variables (which appear to the use the same as
fields) and you can trigger ui controls such as popups...

Jack's suggestion of the padlock icon might help a bit here.

Best place for me at this point is to let the client decide...

Bill

On Jun 6, 2014, at 12:47 PM, Tim Nevels wrote:

color><param>00000,0000,DDEE/param>AAm I missing the point of what you
are trying to accomplish?
/color>
Tim Nevels (6/6/14 9:05 PM)

On Jun 6, 2014, at 5:37 PM, Bill Weale wrote:

color><param>00000,0000,DDEE/param>YYou can still change variables
(which appear to the use the same as fields) and you can trigger ui
controls such as popups...
/color>
Yes, my READ ONLY, LOAD RECORD approach only works for field on a
form.

I combine this with OBJECT SET ENTERABLE(*;"Field@... to disable
variables based on object names.

For popups use DISABLE BUTTON(*;"popup@... again using a standardized
object naming convention.

You have to come to realize that object names are important in 4D.
They were not in the past, but now they are. So start paying attention
to naming objects so that you can utilize some of the commands that
support object names and the "@... character. It makes your life a whole
lot easier.

Tim
Bill Weale (6/10/14 2:29 PM)

Tim, I understand and I do that. But it's the rest of the story that
causes the issues I'm trying to raise. It's the same problem we
developers face when we have a client that says "I want to do That!"
It's usually very easy to develop a routine to do pretty much anything
a client can describe. The challenge we face and whether 'That'
function really serves the client, though, depends on our developing
safeguards for the times when 'That' doesn't work or when 'That'
shouldn't be executed.

Form object names: Use them the way you and others describe here and
after a few years in a complex project you'll find yourself buried in
alphabet soup. 4D doesn't give us Object IDs, so in a multi-user,
multi-process environment, the Object name is the closest thing we
have for an Object ID. As far as I know, it's the only/best way one
can uniquely identify the object. From my viewpoint it's a key field
for the object.

So, as an example, I can make sure the names of form objects I want to
treat together in code can all contain the same substring. But what if
a few of them should also go with others? As time goes buy it gets
more complex, etc, etc--I'm sure you've been there done that. I see 2
major issues here: 1) you have to continually change (and somehow
catalog) object names and 2) 4D already supports the notion of groups
of objects on a form. I've not done a lot with v 14, but I haven't
heard yet that you can address objects defined as part of a form
group. Why not?

I like Josh's idea of letting 4D name the object--it's one step toward
a unique identifier, but 1) I think the uniqueness is limited to the
realm of the form and 2) it's still very cumbersome to catalog them
and address them by group.

I've always made it clear that I'm not a CS major and I know there are
a lot of "basics" I still need to know. But I *think* I'm talking more
about evolution here and I've taken part in a few fields that have
evolved a lot more and a lot longer than coding and app development. A
lot of the "necessary" coding work we've discussed in this thread and
in the 'Typing ui objects' thread involves what other professions at
this point would be called "grunt work." As it accumulates. it's nice
to have an assistant or a trainee around to handle it, but after a
while theres so much required that someone invents a tool...

;-)

Bill

On Jun 6, 2014, at 10:05 PM, Tim Nevels wrote:

color><param>00000,0000,DDEE/param>YYou have to come to realize that
object names are important in 4D. They were not in the past, but now
they are. So start paying attention to naming objects so that you can
utilize some of the commands that support object names and the "@...
character. It makes your life a whole lot easier.
/color>
Bill Weale (6/10/14 3:07 PM)

Agreed.

The evolution of 4D's "gross" db engine capabilities have taken it far
beyond processing needs of any of my projects. In that classic "80/20"
dichotomy, for me the 20% is for basic db coding for records
management; the 80% is for UI development (but a *significant* part of
that 80% is for continual "upgrades").

8-|

Bill

On Jun 6, 2014, at 12:24 PM, Kirk Brooks wrote:

color><param>00000,0000,DDEE/param>AA good UI leads to better user
experience,
impacts user productivity, impacts the quality of the data (fewer
errors on
a well thought out input/edit form), and so on. So, yeah it is kind of a
lot of work to get right but it's worth it.
/color>
Reply to this message

Summary created 6/11/14 at 8:03AM by Intellex Corporation

Comments welcome at: feedback@intellexcorp.com