Late Control binding to make Forms Field independant.

[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.

 

[Mark_]

I would suggest looking at the Clarion programming language to see if their templated application development is what you are looking for.

 

[RonPaii]

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?

It looks like your trying to replace coding in a language like VBA with coding in the database. IE soft coding like in the Daily WTF article https://thedailywtf.com/articles/Soft_Coding.

IMO designing the data model is the more difficult part of programming a database application.

 

[Imb]

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.

@DHookom,

The sample database with your specs is ready.
I can attach the DHookom.mdb and the DHookom_data.mdb, but not the General.mde.

How can I solve this?

 

[tvanstiphout]

How can I solve this?

Zip files can be attached as well.

 

[Imb]

I would suggest looking at the Clarion programming language to see if their templated application development is what you are looking for.

@Mark_,
Thank you for your answer. I don't think I need Clarion on this moment
In my approach I have 2 templates, one for a continuous form, and one for all the rest. That is not the problem. The problem with Access - in my opinion - is that the form, and thus its controls, are based on the fields in the record.
And this makes that you need a separate form for each table.
Furthermore you need per control BeforeUpdate and AfterUpdate events - if necessary - to accomodate for the business rules.
If you place all these things outside the form, then you can use the same form in many situations.

But where is than the connection between control and field?
When you enter a control, the control description is retrieved from the metadata-table, where its behaviour is stored, including the table, field, and fieldtype for data storage.

 

[Edgar_]

Based on previous talks with OP, I think the method is using unbound forms with many unbound controls each. On form load, OP maps some table to the unbound controls and hides unused controls. He then attaches common behaviors to the controls in use. I suppose the tables contain the metadata to customize the whole thing. But yes, a sample would be better.

 

[Imb]

@DHookom,

The sample database with your specs is ready.
I can attach the DHookom.mdb and the DHookom_data.mdb, but not the General.mde.

How can I solve this?

@DHookom,
I have the zipped application at hand.
But I have to modify the sample a little bit, because the word "GROUP" is a defined word, so I need to change that.
I define my items as singular, Group_tbl, Group_id, I have to change that first. But now it is too late
That is a pitfall that I am not used to, because I would "normally" use Groep.

 

[Imb]

Based on previous talks with OP, I think the method is using unbound forms with many unbound controls each. On form load, OP maps some table to the unbound controls and hides unused controls. He then attaches common behaviors to the controls in use. I suppose the tables contain the metadata to customize the whole thing. But yes, a sample would be better.

@Edgar_,
You seem the only one who understands the principle.
What you sketch is the way I work with continuous forms, because these need a recordset. A minor difference is that I unhide the used controls.
The metadata table in the FE with the control specifications, customizes the whole thing.
Probably another "minor" difference is that the (dummy) controls are default ZLS. That makes the internal programming half as simple. Only at storage the Null comes in view again.

 

[Imb]

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.

I am very disappointed that you say "you refuse us ..."

I really did my best to do the opposite. But I think the models that we have in mind differ. Whatever I say, with my model in mind, is probably interpreted a little different with your model in your mind.
Your solution - from your point of view - is to PRESS on a sample, but for several reason (I am not having all the skills to serve you) that did not match my possibilities.

 

[Mark_]

@Mark_,
Thank you for your answer. I don't think I need Clarion on this moment
In my approach I have 2 templates, one for a continuous form, and one for all the rest. That is not the problem. The problem with Access - in my opinion - is that the form, and thus its controls, are based on the fields in the record.
And this makes that you need a separate form for each table.
Furthermore you need per control BeforeUpdate and AfterUpdate events - if necessary - to accomodate for the business rules.
If you place all these things outside the form, then you can use the same form in many situations.

But where is than the connection between control and field?
When you enter a control, the control description is retrieved from the metadata-table, where its behaviour is stored, including the table, field, and fieldtype for data storage.

Fundamental differences between storing code to control behavior for a field in a table and how Clarion does it with templates are
1) Clarion is a compiled language. Updating the template and recompile to achieve updates rather than update code in a table. Benefit is you get the speed of it being a compiled language without needing to do extra file access for table lookups.
2) Templates normally can be turned on/off on a per-field basis. Means you can have two fields of the same type but each handled differently depending on need. Example could be using a generic calendar for one entry and a custom "Scheduling" calendar that also adds the appropriate linking record when entering a scheduled date.
3) There are a LOT of templates you can get or make for Clarion. The template language is relatively straight forward.

 

[Imb]

IMO designing the data model is the more difficult part of programming a database application.

I agree, that a good design of the data with respect to the relations is the basis for a good robust application.
But I don't "accept" that the forms have to follow that design.

In my applications I have utilities that, when you used a wrong relation between two entities, you can convert that.
So, when you have one field in a table table that could be better a relation to another table, you can convert that. And also the other way around. Because of the "dynamic" forms you don't need to change any form!

The same holds when you add a field to a record, or delete it, "forms" are automatically adjusted.

 

[Imb]

Fundamental differences between storing code to control behavior for a field in a table and how Clarion does it with templates are
1) Clarion is a compiled language. Updating the template and recompile to achieve updates rather than update code in a table. Benefit is you get the speed of it being a compiled language without needing to do extra file access for table lookups.
2) Templates normally can be turned on/off on a per-field basis. Means you can have two fields of the same type but each handled differently depending on need. Example could be using a generic calendar for one entry and a custom "Scheduling" calendar that also adds the appropriate linking record when entering a scheduled date.
3) There are a LOT of templates you can get or make for Clarion. The template language is relatively straight forward.

Can you also have ONE template for continuous forms and ONE template for all the rest?
And this template (these 2 templates) work for ALL applications?

 

[Mark_]

Can you also have ONE template for continuous forms and ONE template for all the rest?
And this template (these 2 templates) work for ALL applications?

Yes. More importantly you can assign specific templates for specific needs so you DON'T have to use a giant template. Think of it more as "I get to turn on and off specific functions on a per control basis".