Late Control binding to make Forms Field independant. (2 Viewers)

[Imb]

I am looking for some "soulmates", who are working on the subject of Field independant Forms, to start a discussion for further exploration.

In standard Access forms are bound to a RecordSource. In this way the form knows which controls can be used, where to find the values, and where to store the updates.
But the business rules for the controls (user-controls) are must also be applied. For that reason the control has BeforeUpdate and AfterUpdate events to make the control "user friendly", or context specific.
The drawback is that the form is now field dependant, static, and absolutely not shareable.

Workarounds are used to make the forms or the controls more "shareable", with Form classes, or Control classes, but what I read in literature this only benifits in certain niches, and makes code more complex.

I took a different direction, starting with the user-controls.
In a (metadata) Veld_tbl I collect all the business-rules (in FE), and based on that I define the tables and its fields in my development application. This means that - without any form - all information about the behaviour of the user-controls is already available, including the user-controltype, which is far more structured then the fieldtype.
To design a user form, I can just use an dummy form with some dummy controls. During opening of the form the dummy controls are tuned using the information from the Veld_tbl: they are positioned, and diversified according to their task, with a reference to the Veld_tbl.
When an event of a dummy control is triggered, a general procedure handles this event. For example, in the Enter event the "On_ctl_Enter" procedure is run, which activates the appropriate record of the Veld_tbl. When moving to a different control "On_ctl_Exit" procedure is run, handling the business rules, and if necessary, save the changed values. Each control always runs the same procedure per event.

This in a nutshell the process. The same dummy form can be tuned for a complete different task, but with a reference to right Veld_tbl record, the control always reacts in the same way, independant of the form.

As a result, all information on a user-control is stored in a FE-table, and how a table is tuned in a general module.
In this way it is very easy to have an overview over may different applications. No commercial software needed to monitor the different applications. Moreover, almost all underlying processes are generalized (they only need the reference to the Veld_tbl to make them specific) and can be shared in a linked library database.
But much more details can be told about this approach.

Who is really, really, really interested to spit this subject further out?

 

[GPGeorge]

For starters, could you post a sample database illustrating the technique? Start with something simple. Show us how it works to get a conversation started.

Thank you.

 

[Imb]

For starters, could you post a sample database illustrating the technique? Start with something simple. Show us how it works to get a conversation started.

Thank you.

@GPGeorge, @isladogs,
My problem with a simple sample database, is that it works an almost any sample databases, only without too much cosmetics.
The added value is that the database is almost complete automatically generated, independant of any user-definition.
For starters with programming there is no fun, because most is already included. This approach is interesting for small scale organizations (non-profit?) that want a quick-start application, but not the developping part.

I really understand, seeing the code can explain much about the internals of an application.

On this moment I do not want to publish the code for the whole world.
It has still a couple of bugs that are not yet solved, it has many parts of redundant or wrong code because of the evoluation history, most is not yet in an international language and many more of these inconveniences.
When I publish the code, it will be there for "eternal", and I "only" will be accounted for the things that do not work, I fear.

To publish the topic in an UserGroup would cost me too much time to make a presentation. I first have to learn all these techniques! But again, alas, the attendees want to see/use the code, and I first want to improve that.

Therefore I prefer the discussion. This can de done in a small group, in some Zoom session or a private visit, with interested developpers, where I can share my thoughts, including examples, and code.

I had hoped that I did find some discussion partners here, but - seeing the reactions - I am afraid I have to conclude that most of the developpers are so focussed on classic Access that there is no appreciation or identification for non-standard use of Access.
But who knows?

 

[DHookom]

@GPGeorge, @isladogs,
My problem with a simple sample database, is that it works an almost any sample databases, only without too much cosmetics.
The added value is that the database is almost complete automatically generated, independant of any user-definition.
For starters with programming there is no fun, because most is already included. This approach is interesting for small scale organizations (non-profit?) that want a quick-start application, but not the developping part.

I really understand, seeing the code can explain much about the internals of an application.

On this moment I do not want to publish the code for the whole world.
It has still a couple of bugs that are not yet solved, it has many parts of redundant or wrong code because of the evoluation history, most is not yet in an international language and many more of these inconveniences.
When I publish the code, it will be there for "eternal", and I "only" will be accounted for the things that do not work, I fear.

To publish the topic in an UserGroup would cost me too much time to make a presentation. I first have to learn all these techniques! But again, alas, the attendees want to see/use the code, and I first want to improve that.

Therefore I prefer the discussion. This can de done in a small group, in some Zoom session or a private visit, with interested developpers, where I can share my thoughts, including examples, and code.

I had hoped that I did find some discussion partners here, but - seeing the reactions - I am afraid I have to conclude that most of the developpers are so focussed on classic Access that there is no appreciation or identification for non-standard use of Access.
But who knows?

If this is all true then it makes sense to not post your ideas in threads where they will never result in any level of support. I assume you could contribute some minor, repeatable, implementable ideas that could help someone. I see lots of posts that move away from hard-coded designs to a more flexible solution.

 

[Imb]

@Imb, if you could post a very simple demo of your system for something as basic as managing a mailing list with the ability to create groups. In a standard Access app, this would require about three tables and three forms.

My best guess is your system tables would resemble the results of the database documenter where the definitions and properties
of all Access objects are stored tables. I suggested this in the past but you said no.

@DHookom,
Something like:

Person_tbl
Person_id PK
Lastname
Firstname
Mailaddress_tbl
Mailaddress_id PK
Mailaddress
Mailgroup_tbl
Mailgroup_id PK
Person_id FK
Mailaddress_id FK

 

[DHookom]

@DHookom,
Something like:

Person_tbl
Person_id PK
Lastname
Firstname
Mailaddress_tbl
Mailaddress_id PK
Mailaddress
Mailgroup_tbl
Mailgroup_id PK
Person_id FK
Mailaddress_id FK

I was expecting:
Persons
PersonID PK
FirstName
LastName
Address
Phone
Groups
GroupID PK
GroupName
PersonGroups (Junction table)
PerGrpID PK
PersonID FK
GroupID FK

I would add to the confusion of multiple persons at the same address or multiple phones or phone types. Just the very basics.

 

[GPGeorge]

@GPGeorge, @isladogs,
My problem with a simple sample database, is that it works an almost any sample databases, only without too much cosmetics.
The added value is that the database is almost complete automatically generated, independant of any user-definition.
For starters with programming there is no fun, because most is already included. This approach is interesting for small scale organizations (non-profit?) that want a quick-start application, but not the developping part.

I really understand, seeing the code can explain much about the internals of an application.

On this moment I do not want to publish the code for the whole world.
It has still a couple of bugs that are not yet solved, it has many parts of redundant or wrong code because of the evoluation history, most is not yet in an international language and many more of these inconveniences.
When I publish the code, it will be there for "eternal", and I "only" will be accounted for the things that do not work, I fear.

To publish the topic in an UserGroup would cost me too much time to make a presentation. I first have to learn all these techniques! But again, alas, the attendees want to see/use the code, and I first want to improve that.

Therefore I prefer the discussion. This can de done in a small group, in some Zoom session or a private visit, with interested developpers, where I can share my thoughts, including examples, and code.

I had hoped that I did find some discussion partners here, but - seeing the reactions - I am afraid I have to conclude that most of the developpers are so focussed on classic Access that there is no appreciation or identification for non-standard use of Access.
But who knows?

The real problem is that you do not provide any information specific enough to interest others in looking into your techniques.

Statements like this are both intriguing and frustrating.

"The added value is that the database is almost complete automatically generated, independent of any user-definition."

Intriguing because the promise is that one can somehow completely generate a full database with little or no design effort.
Frustrating because, despite the many decades of collective experience of members here, you refuse to share with us even a slight hint about HOW that happens.

One thing that might be of value in establishing credibility would be a small sample. Since that isn't available, maybe tell us about some of the clients for whom you've implemented solutions based on the method. The kind of business they're in, the data handling and tracking that your solutions provide for them, how long they've been using the solutions, and so on. Give us some idea of how well it works in practice. Help us get past the initial vagueness.