Late Control binding to make Forms Field independant. (1 Viewer)

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