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

[Albert D. Kallal]

I think the issue to garner interest is you have to make a really great case as to why this approach is going to benefit the typical Access developer.

So, as always, there should be a tangible benefit here, and one that developers see this, and go, gee, I want to do this!

I mean, right around the time of FoxPro, and a few more programs in the early PC days? (DOS, screen based systems).

These so called 4th GL or so called “code generators” were really common. And ONE big reason these “code” generator systems were common is that those older systems did not have the concept of a object. So, to layout a screen, they generated code. FoxPro power tools comes to mind (it was too time consuming to do all those input @ signs with a x and y coordinate system - so, power tools to the rescue was the solution (until later on, FoxPro had it's own form designers built in).

So, the idea being floated here is: "to enable control re-use".

Is that really the goal? I mean, we have a re-usable tool box of controls.

There’s not a lot of benefits to re-using a control on a form vs that of simply dragging one from the toolbox into the form.

However, what is common and a way to re-use controls and bits and parts in other systems?

Well, be it .net desktop, or even asp.net – especially web forms?

They introduced the concept of a “user” control. That is a custom control with specific behaviors that one could use over and over.

However, great, we have a re-usable “user control” – now what????

Yes, I actually mean this – now what? Or so what?

You see re-use of a built-in text box, or a custom one? Nah, no real benefit.


However, re-using a set of controls with a SPECIFIC purpose, one that you can use over and over? Ok, now we are talking!!!!
Re use of controls does not "just" occur, it will occur with a goal, and specific purpose in mind.

While I just lamented that Access does not have the concept of “user controls”?


Well, it turns out there are some really nice workarounds – and they are called sub forms.

Most don’t realize that when building Access applications and using forms + sub forms? One is actually cobbling together a set of objects – and those sub forms can have a HIGH re-use factor. It also allows complex data modeling, and often without requiring code.


A simple example?

Say throughout your application you need to display your company address in quite a few places (forms, and even reports).


So, build a form that displays the company address, and now you can drag + drop that pre-made and re-usable “object thing” into any form or report.

Hence this:

Or, say this:

In above, I dropped in the sub form 3 times!!!!
(and you not making copies of that sub form - it is a true new object instance of the original sub form).

How about we need to prompt the user for a start date, and a end date (super common goal). Well, once again, build a sub form that does this for you (and use me.Parent to pass the selected values to the parent form – even to run code in the parent form).

So, you have a form, but you want to use it for VAST different purposes (so, that trick of sending events from the sub form to the main form is the magic here).


So, now we have this:

Or this form:

Note in the above 2 date prompt forms? We are NOT even coping the sub form, but 100% re-using the subform – you can’t get better then actually “using” the ONE same form over and over.

And the big bonus points? Well, then your UI is being re-used over and over - you thus have a more consistent UI experience.

So, keep in mind the real power of say "user controls" in .net for desktop for web?

It not that you re-using "some" controls, it's that you can create a UI widget that can be used over and over with a specific purpose.

My "guess" is that since Access can do the above?
And since coming from other platforms that do, and did have user controls?

Well, until I grasped the above concept (of subforms = re-useable sets of controls), then I did miss the concpet of re-usable controls.

However, in all these years, the goal was not just I want to re-use some control, but that of cobbling together a few controls with a specific purpose was the reason here. So, the challenge here is not "just" to re-use some controls, but to re-use them with a given purpose you design for the given application (like an address, or the "many" times and places you will need a start + end date prompt).

So, I'm not really convinced that using meta-data to drive controls on a form at runtime going to yield a lot of benefits like the above examples.

However, there may well be some really great use cases in which this approach yields benefits to an Access develpoer.

The real issue?
Well, Access tools are really great, they are RAD, and for the most part it's going to be difficult to come up with a better design model and approach then what we have with Access now. Might be "some" benefits, but they will have to be noteworthy and significant to garner interest from the general Access community.....

I in no way want to throw "cold" water on some of these re-use ideas you are floating here - but the case will have to be really compelling with some really great use examples (such as I shared above) that would then generate increased interest in such concepts.

So, have I in the past done some forms in which I change the properties, and bind the data sources at runtime? Yes, I have, but such use cases are rare for the benefits, and I think for most, the above sub-form approach will suffice for a significant portion of "re-use" goals for Access developers.


R
Albert

 

[Edgar_]

I in no way want to throw "cold" water on some of these re-use ideas you are floating here - but the case will have to be really compelling with some really great use examples (such as I shared above) that would then generate increased interest in such concepts.

There is already notable interest in OP's solution. Many members of the community have shown some level of interest in seeing it in action and experimenting with it. In fact, if there was no interest, we would not have made it to page two of this thread. The idea behind it seems solid. Many of us can recall times when we had to repeat similar design decisions, and the concept of dynamically generating controls has come up in discussions before. OP's solution appears to address this by creating a flexible set of controls that can adapt to a variety of use cases, streamlining the process. It is not that we cannot build it ourselves, but that it seems like a lot of work and it would be interesting to test, based on OP's claims.


While we have not yet had the chance to try a sample, as we have only seen screenshots, one thing is clear: Access is not naturally suited for dynamic forms. It excels at building reusable static forms, like the one shown in your example, but OP's approach seems to take it further. This is not just about creating forms; it is about a development methodology where the focus shifts to managing the tables and the solution handles CRUD operations automatically. This is a new way of looking at app development in Access, and it has potential. That is my opinion, of course.


Furthermore, there is no need to dismiss any new idea too quickly. I believe that all attempts to improve the development experience are valid and should have a place in these discussions. New approaches often lead to better understanding, better tools, and better outcomes for everyone. We should encourage this kind of experimentation because progress on any platform depends on people willing to explore new possibilities. There is no reason to treat Access in the same way that its owner treats it, especially when the community keeps finding creative ways to extend its usefulness while Microsoft seems to be trying to make it less relevant. So, I will respectfully disagree with you on the quoted statement. Compelling or not, it sounds interesting at the very least.

Edited, it sounded like I was scolding or something.

 

[Albert D. Kallal]

There is already significant interest in OP's solution. Many members of the community have expressed some degree of desire to see it in action, to play with it. In fact, we would not be on page two of this thread if that were not the case. The concept behind it is solid. Many of us can recall situations where we have had to repeat similar design choices, and the idea of dynamically generating controls on the fly has been a recurring theme in discussions. OP's solution seems to address this need by creating a flexible set of controls that can adapt to a wide range of use cases, streamlining the process. It's not that we can't build it ourselves, but that it seems to be quite a bit of work and it would be fun to test, based on OPs claims.

While we have not had the chance to experiment with a sample yet, we've only ever seen screenshots, one thing is clear: Access is not naturally suited for dynamic forms. It's great at building reusable static forms, like the ones in your example, but OP's approach takes that a step further, apparently. This is not just about form creation, but rather a development methodology where the focus shifts to managing the tables, and the solution handles the CRUD operations automatically. It is a fresh perspective on app development within Access and it has potential. That's of course, my opinion.

Also, there is no need to throw "cold" water on any fresh idea. I believe that all attempts to improve the development experience are valid and have their place here. New approaches often lead to better understanding, better tools, and better outcomes for everyone. We should encourage this kind of experimentation, because progress in any platform depends on people who are willing to explore new possibilities. There is no reason to treat Access in the same way that its owner treats it, especially when the community continues to find creative ways to extend its usefulness while Microsoft finds creative ways to hide it from the world. So I will respectfully disagree with you on the quoted statement, compelling or not, it sounds interesting, at least.

Well stated.... I only pointed out the above approach (sub forms) as one great approach to building and reusing controls.
And as I stated, I have in the past built a form that was driven by a table in which the colluns, their data source etc was defined. So, I've done this in the past. However I found the use case(s) limited - and that may Well be limited to my experiences.
Regardless, sub forms are not often seen as a great way for control re-use, and thus was happy to share how I view and use sub forms not only to show child data, but a great means to build sets of reusable controls.

As noted, we can't sub class or inherit existing controls like say in .net, so as others pointed out, Access is not really all that great for the proposed design pattern being floated here- we are limited. So while I've even used this approach, I can't make a great sales case. But then again, that's my use case, and people's mileage as to the benefits of this approach will vary. So, because I'm not sold on this approach? That's my view, not others here....
R
Albert

 

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

Here a really simple sample.
Place DHookom.mdb and General.mdb in some map.
In the map you make a submap Data, to store DHookom_data.mdb, and also a submap Temp for report-output.
(Dbl)Click on DHookom.mdb to start the application.

Pressing one of the three buttons (Persons, E_Groups, PersonGroups) show the correspoding records, that can be filtered whith a RightClicking on the button.
A new record can be added with the Nieuw button, and stored with "Opslaan".
Each record will have a yellow button, that can be pressed to edit that record.
To wipe out any value, use the Esc-button.

The PersonGroup displays a junction table. In this case you don't type a value, but select a FK-record. To start, press a space key, or type the first letter(s) to start the selection. Finally, press the blue button to accept that record.

To close a form, press the Stop button (or RightClick to close the application)

Success.

 

[Imb]

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.

@RonPaii,
No, not that I am aware of.

What I do is write code in VBA to automate the underlying processes. These are parameterized to accomodate any Item/Entity and are independant of the form. All error handling is included in code of these processes.
Because the code is independant of a form, and control-specific information is stored in a metadata-tbl, the respective code is generic to any application that is connected to General, the library database.

 

[RonPaii]

@RonPaii,
No, not that I am aware of.

What I do is write code in VBA to automate the underlying processes. These are parameterized to accomodate any Item/Entity and are independant of the form. All error handling is included in code of these processes.
Because the code is independant of a form, and control-specific information is stored in a metadata-tbl, the respective code is generic to any application that is connected to General, the library database.

Are you binding events in user defined classes to these controls?

 

[Imb]

Are you binding events in user defined classes to these controls?

No, I don't use user defined classes, no form classes, no control classes.

I have (the same) form, with a number of dummy controls, that on opening the form, are placed, dimensioned and and layed-out according to their further meaning, defined by a Veldtype, and they get their initial value.
For simplicity and efficiency the dummy controls are "just" TextBoxes.

Each control runs exactly the same event procedures.
In the whole concept I use in fact ONE control. That is the one that is entered. All the other controls just display their value, nothing more.
The Enter-event looks at the Veldtype, and reacts accordingly: as Label do nothing, as Commandbutton run a procedure like a Click_event. And with a field-related Veldtype, "bind" the control to a record in the metadata-table.
After an Enter inevitable, an Exit-event must be triggered, in which changed data is stored.
So instead of all kind of control classes, I only use the Veldtype.
The distinction between the Veldtypes is very easy:

Select Case Veldtype
Case "A": Do_A
Case "B": Do_B
Case "C": Do_C
...
Case Else: Do_the_rest
End Select

 

[Isaac]

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?

Isn't this like the Nth post you've made, trying to start this fire to no avail?

 

[Imb]

Isn't this like the Nth post you've made, trying to start this fire to no avail?

This is not the tone in a friendly forum, it is absolutely not constructive, and only denigrating.
I will have to report this.

You were trying to be funny?

 

[DHookom]

@DHookom,

Here a really simple sample.
Place DHookom.mdb and General.mdb in some map.
In the map you make a submap Data, to store DHookom_data.mdb, and also a submap Temp for report-output.
(Dbl)Click on DHookom.mdb to start the application.

Pressing one of the three buttons (Persons, E_Groups, PersonGroups) show the correspoding records, that can be filtered whith a RightClicking on the button.
A new record can be added with the Nieuw button, and stored with "Opslaan".
Each record will have a yellow button, that can be pressed to edit that record.
To wipe out any value, use the Esc-button.

The PersonGroup displays a junction table. In this case you don't type a value, but select a FK-record. To start, press a space key, or type the first letter(s) to start the selection. Finally, press the blue button to accept that record.

To close a form, press the Stop button (or RightClick to close the application)

Success.

The folders were created and tables relinked except I couldn't find [Selectie_tbl]. Also the database won't compile since it is missing some reference. Maybe the general.mdb needs to be configured.

 

[tvanstiphout]

@DHookom: the app compiles for me (A365-32).
Do you need to decompile?

 

[tvanstiphout]

@Imb: I entered a few persons and groups, then tried to associate a person to a group.
Clicking on New PersonGroup I get this form, with yellow textboxes where I was expecting comboboxes. I read that you mostly use textboxes. Are we supposed to type the names here?
I found out that in other forms I can select a group, or a person, and then those values will show here. I was not able to open both the person form and the group form, but assuming that is a minor bug, is that how this persongroup form is supposed to work?
Later I found that typing the first character in a yellow field opens the corresponding List form. Is that to make a selection, so you don't need to use a combobox?
I was not super happy with how that worked and was never able to create a persongroup record. Can you give me the step-by-step, or post a video?

 

[The_Doc_Man]

I'm not going to comment directly on any technical issue. However, I have to point out that the purpose of Access is to perform Rapid Application Development such that you can generate queries, forms, and reports nearly automatically and then drag-n-drop, drag-n-resize, or otherwise adjust their appearance once you've got the controls set up for all of the fields. By using a "template form" that had a lot of the common event code already in it - sometimes fleshed, other times stubbed - I was able to very quickly generate forms with a common look-and-feel in about 40%-60% of the time of starting each form from scratch, keeping the forms relevant by adding in the desired fields to renamed copies of the template. This approach is somewhat like a compromise of traditional methods and your methods.

You are reversing the Access design paradigm by starting with a "magic" form and then feeding it data. Of course, the Access wizards do what they do with data first and generated objects second. Which, OF COURSE, is the way Access is designed... data first, other features later. It is interesting that there is enough power in VBA to allow this treatment to occur, and you are to be commended for taking a different viewpoint. Thinking out of the box is very useful - sometimes.

However, there is always this question: Is it worth the effort? If you are doing this because you were curious to see if it could be done, it looks like you've got some answers. Good for you. But for most folks, the straight-forward development paradigm is why they chose to do what they did in Access using the "normal" way of doing things. Also, there is the issue that if someone else is to take over maintenance of the project, they need to be on board with your methods. Since you cannot design forms your way by referencing the traditional Microsoft Learn library, I hope you wrote up some good documentation.

I will also say that I have seen so-called self-designing databases - such as the one offered by PeopleSoft. They claim to generate fully functional databases given the data schema that you feed in. I watched that product flop because the essence of self-designing code is that you must have a library of templates or "drivers" to handle each data type. And you can't afford to have any unhandled types if that is your business line. When you have unhandled things, life isn't very kind - whether we are talking data or run-time errors.

I absolutely DO NOT criticize your work or your results. I merely wish to point out that not everyone will share your motives or concerns because Access isn't supposed to be FE-heavy.

 

[Imb]

@Imb: I entered a few persons and groups, then tried to associate a person to a group.
Clicking on New PersonGroup I get this form, with yellow textboxes where I was expecting comboboxes. I read that you mostly use textboxes. Are we supposed to type the names here?
I found out that in other forms I can select a group, or a person, and then those values will show here. I was not able to open both the person form and the group form, but assuming that is a minor bug, is that how this persongroup form is supposed to work?

@tvanstiphout,

The PersonGroup_tbl is a junction table, and its fields are FK fields. That is a different "Veldtype" then some text.
If you type a character (space or any other) then a new form is opened with the (filtered) records of the underlying Item, i.e. Person of E_group. If this form has records, you will see a "blue" control. When you click that control, the selected record will be used to make that connection between the PersonGroup_tbl and the Item Person of E_group.

When your wanted Person is not yet displayed in the form, you can press the Nieuw button, to add your Person to the list. The after saving, the new Person-record has a blue control that can be pressed to make the connection.
After both defining a Person and (in the same way) a E_group, you can save (Opslaan) the PersonGroup record.

If the Person-record would also have a PK-field, and has to be filled in before saving, you can work in the same way: select a related record, add a new on if necessary, and save. This cascading can continu until all memory is used.

I can imagine that you are not lucky with this approach after some time experimenting, after you have done the classical yoiur whole life.

So, no comboboxes, but a "full main form" to have far more information available than in the combobox-list. Plus that you can go many levels deep.

I hope the will help you.

 

[Imb]

I read that you mostly use textboxes.

@tvanstiphout,

I use only TextBoxes. But here is a difference of interpretation.

In your classic model you can use a listbox to select a value, or a record. In my concept I do not use that.
I use the TextBox as a really dummy control, with absolutely no user-information. It is just a show-element on a dummy form. But it has the necessary events to make such a control attractive to the user, in terms of position and appearence.
But it has also an Enter-, Click- and Exit event. In the Enter event it is given the user information (Late Control Binding) to react as it is supposed to.

 

[Imb]

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.

@GPGeorge,

In the meantime there is a little demo database uploaded, so you can see HOW things happen.

One project is called "Archief", that tries to relate almost anything that "has happened" in a middle sized town with about 30,000 inhabitants, including persons, activities, addresses, businesses, leisure, ...
It started about in 2001. Here you see the extent of the project:

A second one, started around 2005, is a Postcode-database, that is referenced from any of my applications containing an addressing system:

 

[Isaac]

It was brought to my attention that my post could be construed as mean, and it's true that I'm not God - I can't be positive of your intentions, I can only make a guess. Thus I apologize for my post wherein I questioned your motives for starting this topic again - I mean, for the way I said it, not for the questioning itself. I could have been nicer.

 

[isladogs]

Can you explain why the container count shows Forms = 0 in both screenshots for post #36 when there are clearly 2 forms visible in both cases.

Also are you able to provide a 64-bit version of General.mde so I can look at this simple example?

 

[Imb]

I think the issue to garner interest is you have to make a really great case as to why this approach is going to benefit the typical Access developer.

So, as always, there should be a tangible benefit here, and one that developers see this, and go, gee, I want to do this!

I mean, right around the time of FoxPro, and a few more programs in the early PC days? (DOS, screen based systems).

These so called 4th GL or so called “code generators” were really common. And ONE big reason these “code” generator systems were common is that those older systems did not have the concept of a object. So, to layout a screen, they generated code. FoxPro power tools comes to mind (it was too time consuming to do all those input @ signs with a x and y coordinate system - so, power tools to the rescue was the solution (until later on, FoxPro had it's own form designers built in).

So, the idea being floated here is: "to enable control re-use".

Is that really the goal? I mean, we have a re-usable tool box of controls.

There’s not a lot of benefits to re-using a control on a form vs that of simply dragging one from the toolbox into the form.

However, what is common and a way to re-use controls and bits and parts in other systems?

@Albert D. Kallal,

Thank you for your reply.
Your definition of a re-usable control is completely different from mine.
Referring to my definition you use duplicates of predefined controls, on a predefind form. So your forms are always dedicated to a certain situation.
I have been working on generalization of Access applications, to make the code robust, and re-usable.
You can continue, and continue with that process, until you meet the forms. Forms are not to generalize!
You can make "workarounds" with classes, but then you create code to identify that certain forms are "comparable" in behaviour. The same holds for controls, organized in classes.
The underlying problem is that forms are in one way or the other way is still dependant of the business rules.
Just an example, when you copy (dragged or not) a Boolean control, the form "demands" that the control is linked to a Boolean field in a record.

So to generalize forms, they must be absolutely independant of any Business interpretation. Therefore the form becomes a container of really dumb controls. In the Enter event of that control it is told how this control must behave, that is the binding to Fields and Business rules. My interpretation of re-usable controls.

It then becomes possible to generalize the underlying processes, independant of the data.
Building a new application is not "fun" anymore for developpers. The application I uploaded, "DHookom", was build in less than three minutes.

 

[Imb]

Can you explain why the container count shows Forms = 0 in both screenshots for post #36 when there are clearly 2 forms visible in both cases.

Also are you able to provide a 64-bit version of General.mde so I can look at this simple example?

@isladogs,
No, no explanation.
Possibly the right part of the form is some remnant of some test for positioning.
It is a loop through the Containers collection, with the Name of the Container, followed by the Count of the Documents in that Container.

About your next question, I still work with a 32-bit Access, so no possibility to convert to 64-bits.
What I can do, is to send you, on a personal basis, the complete code of General, including a multitude of extended possibilities. But I surely do not want to upload this code to this forum: first the General needs a firm clean-up.