Custom Properties on Controls - possible?

[Brant Burrow]

Hello!

Although I have a fair amount of experience in the Access
and SQL sandbox, I'm just starting to get (seriously) into
Object Oriented Programming ... and, I fear that Access
may not be up to the OOP solution that I would dearly like
to implement. So, I figured I would ask for a heads-up in
this forum. (I'm developing in Access XP/2002 by the way,
in case it makes any difference.)

What I would like to do, is add some custom properties to
Access' built-in controls (i.e. anything that could be
placed on a form). Now, from what I have been able to
gather, this type of solution (in a truly OOP environment)
would involve developing new classes which inherit/extend
from the existing Access classes (controls). And,
although Access supports writing custom classes, I don't
think it support extending its own "internal" classes
(please correct me if I'm wrong).

As a compromise, I would be willing to use a routine each
form's Open event, to add custom properties to all of the
controls on that form. But, so far, I haven't been able
to make the CreateProperty method work for controls (and,
based on the fact that Controls are not part of
the 'Applies To' list in the help for the CreateProperty
method, I don't hold out much hope there <grin/shrug>).

I need to have some user-security based properties that
mirror - conceptually - various native properties (such as
visible, locked, etc.). Based on reading in settings from
a security table in the database, I need to set the
custom "UserVisible", "UserLocked", etc. properties
according to what the logged in user is "authorized" to
do. The reason I cannot simply set the 'real/native'
properties directly, is because many of the forms will
have dynamic behaviour - i.e. even for a "super user",
various fields will not appear, unless a certain option
button is pressed, or a tick box filled in, etc. However,
a subset of these same related fields may very well be
disabled for "lesser" user, and therefore, should not be
made visible. Hence, the need for a 2nd set of
behavioural properties to "mirror" the 'real/native' ones.

(I intend to include logic to ensure that stupid things
don't happen - like disabling a truly 'required' field,
etc.)

That's why I figured the most elegant solution would be to
create custom classes (such as clsTextBox, etc.) based on
the existing controls.

Any guidance/insight would be very much appreciated!

Regards,

Brant Burrow, M. Prog.
Director, Technology Services
G. & H. Burrow Ltd.

 

[Paul Overway]

What you are trying to accomplish CAN be done using native control
properties....you just need to change your mindset. In any case, it appears
that you are attempting to implement some type of "home grown" security
schema....and that will never work. It will be easily circumvented and
therefore a waste of time, and a source of embarassment once this is found
out. What you need to do is implement user level security within
Access...and base what is displayed/enabled/etc on the user's permissions.

 

[Guest]

You're right, that *would* work ... if the spec for the applicatoin allowed the security restrictions to be hard-coded at developpment time (in which case, that would be a lot easier). But, I need to give the user control over defining new users and/or revising existing user (on an on-going basis), in terms of who has access to what (i.e. some fields will initially be view-only for some users, and as they become better trained in the company procedures, etc., the fields will be "unlocked", etc.). That's why I need to implement the application security in a more dynamic fashion

I know that I could always set up an array as each form loads, to read in the various dynamic security settings from a table, and then I suppose I could just use the control index (i.e. item number) to co-ordinate the built-in control properties with the "extended" properties in the array. But, I was just hoping that I could do it in a cleaner fashion - namely, add the extended properties directly to the control, so that I could reference them the same way one would reference the native properties

However, indications are that this is not possible, so I'll just go with using an array

Thanks