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

[isladogs]

OK thanks. My email address is below.
All being well, I'll post the file back in the thread as a 64-bit ACCDE

 

[tvanstiphout]

I use only TextBoxes.

That is the biggest rub for me so far.
It leads to more clicks and more forms popping up to get things done. For many of my customers high-speed data entry is very important.
Plus, the aesthetics of it: no dropdowns, no checkboxes, no radio button groups etc. I know beauty is in the eye of the beholder. All those purpose-built controls that we see in every other app are swept aside for what? The choice of one developer, and in service of the bigger goal of reusability?

I'd like to be blown away by what this approach makes possible, and I'm sorry, but I will watch from the fence from now on.

 

[Edgar_]

@Imb
I just tested the sample file and I couldn't make it work. I put all files in the same folder and then a form with a message appeared. After discarding the form with the message, another form opened with 3 buttons. Clicking on them returns error 3043.

A few thoughts about the situation:
1. You've said it's quick to develop with it, but it remains a mystery how that is done.
2. There is a language barrier to overcome because some things are in english but a lot of others are not
3. I could attempt to fix it, but since the project is locked, I can't and shouldn't if I tried to unlock it

 

[The_Doc_Man]

Since you cannot design forms your way by referencing the traditional Microsoft Learn library, I hope you wrote up some good documentation.

@Imb

Given Tom's and Edgar_'s responses, I return to my original comment. Take this as an attempt to give constructive criticism as I offer you a direction I think you need to go to improve your presentation. If you have inadequate documentation, your product is generally useless to anyone but yourself because from the limited sample of some pretty high-powered guys who tested this sample, you are the only one who can make it work.

 

[Albert D. Kallal]

@Albert D. Kallal,

Thank you for your reply.
Your definition of a re-usable control is completely different from mine.

Yes, it is differrent. Keep in mind, that you suggesting benefits arise that the form now does not have that binding information.

However, all you done is move that developer workload to another location - you STILL have to do that work!

Remember, I do a LOT of web development work now, so I well grasp the concept of separating UI code from business logic code.

Asp.net "MVC" is a perfect example of this approach.
(Model-View-Controller).

MVC is a design pattern used to separate concerns in web applications by decoupling the user interface (view), data (model), and application logic (controller). This pattern helps in organizing code in a more maintainable and testable way.

However, you at the end of the day simply shuffling the developer workload from one location (in the form) to another location, not that you eliminate having to do this!

So, while there are benefits to moving as much code and logic out of the UI? There are also MANY benefits to do so!!!!

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.

Sure, but you still having to outline and define that binding process - it's still being done, just not in the form anymore. So, the question then becomes how great are the benefits vs the downsides of this approach?

As noted, right now, since we "often" have to move some code and forms from the internal Access application to that of the customer facing web portal? (a great recent example is after a customer has approved a project, then we present them with the shipping page - and they can edit the shipping address, select other locations they have, and also enter comments). And same goes for approval process - used to be 1000+ lines of VBA code. That code still exists, but now both web site, and VBA/Access desktop uses the .net business object for that code. Hence, one code based is shared between the web site, and the Access desktop. And over time, we are moving more and move VBA code into that business object.

However, at the end of the day, mapping of data from that business object to the UI? We still have to do that work load. The fact that we moved boatloads of code out of our Access forms, and even data binding code out (say for web forms doing the same thing)?

The UI presentation is not just UI, but the UI has to behave in many special ways to achieve a desired result. In other words, the UI is NOT limited to JUST data binding (or removing that data binding), but has to do much more to create a great user experience.

This goes all the way back to people often suggesting that you can build a application using just wizards and have the UI work like magic.

No, you actually can't!!!

The REAL value of such systems is in fact attaching that business logic to that UI interface.

The fact that the business logic is moved out of the form? Don't matter in the sense that such code and UI mapping STILL is required - even if you move it someplace else.

The problem more often then not?

It not that you need or "can" re-use some form (and it's controls - that tends to be easy!).
However, to make great software, that UI will require special love and care. It's never really about some text box that is "bound" or not at design time, but building a UI that allows the end user to do their job. Attempts to eliminate this task don't work, and even .net MVC does not eliminate this issue.

Editing and binding data? Gee, that's not the bulk of application development since that's oh so easy anyway!
(however, you would be shocked in web land as to how people are still hand coding the loading of data from that class, or data source, and manually writing code (hand coding) to shuffle the data columns into that UI - we don't do that in Access, and I don't even do that for my web based software anymore ....

But, just a "shuffle" of data to/from the UI? That's not the hard part, and that's not the high value part that takes effort. That part of the development cycle is REALLY fast - even using bound forms. So, eliminating this task, or even automating it somewhat?

That's not where the developer costs are these days.....

I'll certainly give the sample a try in the next while -- and I appreciate you sharing these ideas here...
So, the concepts of moving as much out of a form? Sure, they are great concepts, but, it's not a 0 or 1 narrative either way on this issue, there are benefits of both approaches....

R
Albert

 

[tvanstiphout]

I put all files in the same folder

Then you did not follow the instructions from the OP. See #24.
Note that the MDE is compiled for 32-bit.

 

[Edgar_]

Then you did not follow the instructions from the OP. See #24.
Note that the MDE is compiled for 32-bit.

Thanks, I wrote that precisely because I wasn't sure what imb meant by map, best guess was folder. Since map = folder indeed, I was able to go further with the example.

I see a lot of features for the textboxes when you double click them, I see a lot of string manipulation, even spell check and online lookup, which is interesting. The search functionality is feature rich too. I'm not too sure, but it seems to overcome the lack of combobox by letting you choose from another form.

So the apps that come out of this framework do seem to do a lot of stuff. It's how it does it that isn't very intuitive, which combined with the dutch feedback, makes it really hard to know what you're doing at first glance.

I suppose that with some further instructions a lot can be done with it. I also triggered a ton of errors everywhere and it even crashed the application a few times, but it seems like a good start.

@Imb
If you think it's worth your time, I'd suggest converting the captions into english and creating a few common applications with it live, so we all can see the benefits of the framework.

 

[tvanstiphout]

Thanks, I wrote that precisely because I wasn't sure what imb meant by map, best guess was folder. Since map = folder indeed, I was able to go further with the example.

I share my mother tongue with the OP so I understood right away. Same for the UI elements in Dutch. I should have translated "map" for you.

 

[Imb]

That is the biggest rub for me so far.
It leads to more clicks and more forms popping up to get things done. For many of my customers high-speed data entry is very important.
Plus, the aesthetics of it: no dropdowns, no checkboxes, no radio button groups etc. I know beauty is in the eye of the beholder. All those purpose-built controls that we see in every other app are swept aside for what? The choice of one developer, and in service of the bigger goal of reusability?

I'd like to be blown away by what this approach makes possible, and I'm sorry, but I will watch from the fence from now on.

@tvanstiphout,

Thank you for your nice words.
First, our niches will be quite different. I suppose you are working with squaremeter-screens for high-speed data entry, my customers have mostly laptop-screens, and are more interested in to find the the right person that is called Petrus, of Petri, or P., or Piet, related to a bunch of other (mostly incomplete) data. That is why I have focussed on flexibility, thus many different "views" on a small screen.
For high-speed data entry you probably use a continuous form, including the business rules, that can directly be edited? You probably need a separate form for each table/query. In this concept all these different forms are automatically generated. Each "column" can be dynamically made editable/uneditable depending on the circumstances.

No dropdowns: instead of a very limited dropdown-list, you get a independant form with all the possibilities of a main form, add, delete, mofications, go some levels deeper, to finally select the right records. In priciple two clicks, ons for opening the dropdown/full form, and one for the select/close dropdown/close form.
But is is different, that is true.

The check- and radiobuttons. These make forms again dependant on user-definitions, and that is what I want to avoid. But that does not mean this functionality is not available!
For "display-purposes" I use only a TextBox, that is tuned to its purpose, including a checkmark for a Boolean. No problem to make a tri-state boolean, or a selection of one-out-of many (radio-button). But also many-out-of-many selections are available. It is not an optical identical situation, but understandable (and in their minds logical) for the pensionado-users.

The status of this project is that I have a prototype, that is fully functional in my environment, but that I want to test for all kind of boundary conditions that I have not been thinking of until now. Therefore the discussion way.

But alas, this forum seems only interested in finished products, and that I can not (yet) deliver.

 

[KitaYama]

But alas, this forum seems only interested in finished products, and that I can not (yet) deliver.

What's wrong with sharing an un-finished product? Others can help you finish it sooner. Your first post starts with:

I am looking for some "soulmates", who are working on the subject of Field independant Forms,

But you’re not sharing anything that can actually be tested. Instead, you keep giving lengthy explanations of how the product will work, and so far—if I’m not mistaken—nobody really understands how it works. The closest anyone has come to understanding the idea is @Edgar_, whose posts are full of phrases like “it seems…” or “I think…”. How do you acually expect to find "soulmates"? Do you expect others to cheer for something they have no idea how it works?

After more than 120 posts in your first thread and 49 posts here, you finally offered a locked file. For some people it throws errors, and even when it runs, no one seems to understand how it relates to the idea of dynamic forms.
At one point, someone suggested that you at least demonstrate how it works using a video clip (in your previous lengthy thread). You replied that you don’t know how to make one. Even after someone (Edgar_?) provided a step-by-step instructions, you still didn’t bother to create it.

And yet you criticize others by saying, “this forum seems only interested in finished products.” Are you serious?
When so many experts who are well known in the Access world wide, clearly state that they are stepping away, that should tell you something is wrong.

Forgive my tone, but just as much as you are exhausted by others, I think others feel the same way about the confusion and unanswered questions you keep creating. I'm not an expert in this field. I simply kept looking into your posts to learn something new, but honestly, I feel I lost a huge time by trying to understand your posts, and now I'm lost more than anyone else.

 

[The_Doc_Man]

I feel I lost a huge time by trying to understand your posts, and now I'm lost more than anyone else.

I must correct you, KitaYama. You are not MORE lost than anyone else. From what I've seen, you are not alone in your pinnacle of being lost. For instance, I am there with you.

 

[isladogs]

@Imb
I share the same frustration as everyone else regarding this (and previous) threads
To remind you, I am unable to test your simple example as I use 64-bit Access.

Back in post #40, you offered to send me by email an MDB version of the General.mde file so I could try it out.
However, it now 6 days later and I haven't received anything from you

 

[GPGeorge]

Spoiler:

@tvanstiphout,

Thank you for your nice words.
First, our niches will be quite different. I suppose you are working with squaremeter-screens for high-speed data entry, my customers have mostly laptop-screens, and are more interested in to find the the right person that is called Petrus, of Petri, or P., or Piet, related to a bunch of other (mostly incomplete) data. That is why I have focussed on flexibility, thus many different "views" on a small screen.
For high-speed data entry you probably use a continuous form, including the business rules, that can directly be edited? You probably need a separate form for each table/query. In this concept all these different forms are automatically generated. Each "column" can be dynamically made editable/uneditable depending on the circumstances.

No dropdowns: instead of a very limited dropdown-list, you get a independant form with all the possibilities of a main form, add, delete, mofications, go some levels deeper, to finally select the right records. In priciple two clicks, ons for opening the dropdown/full form, and one for the select/close dropdown/close form.
But is is different, that is true.

The check- and radiobuttons. These make forms again dependant on user-definitions, and that is what I want to avoid. But that does not mean this functionality is not available!
For "display-purposes" I use only a TextBox, that is tuned to its purpose, including a checkmark for a Boolean. No problem to make a tri-state boolean, or a selection of one-out-of many (radio-button). But also many-out-of-many selections are available. It is not an optical identical situation, but understandable (and in their minds logical) for the pensionado-users.

The status of this project is that I have a prototype, that is fully functional in my environment, but that I want to test for all kind of boundary conditions that I have not been thinking of until now. Therefore the discussion way.

But alas, this forum seems only interested in finished products, and that I can not (yet) deliver.

Actually, we'd be happy with a work in progress that actually allowed others to review and examine the processes. Failing that, as I suggested previously, a narrative description consisting of a step by step of a typical implementation you've deployed to a client. What the process involved, how it works, how the client uses it. Even just screenshots of such a deployed application would go a long way.

Thanks.

 

[MajP]

Although the concept sounded interesting at first I lost interest pretty quick because lmb sounds like the guy pitching a Time Share presentation that you are forced to sit through to get the free weekend at the resort with the all you can eat and drink buffet option. Lots of platitudes and aspirational language and not a clear and concise explanation. So it is hard to sift through all of that. I think I get the premise of "what" it does and potential benefits, but without being able to evaluate something you cannot tell is it actually worthwhile. It may be effective and do what it is designed to do but may not be suitable and employable in real world applications by real people.
I think I get the How but no idea if it is worth the time and energy.
1. Does this simplify a developers time and workload?
2 Is the loss of flexibility and configuration of unique forms out weighed by the ease of developing using the standard form designs?
3. Is transferring the workload from designing forms and control to storing metadata a time and work saver
4. Can the average user employ this.

I am guessing the OP is an engineer and not a sales man or even a project lead. It is great to say it does all these things, but you sell people on something you need to be able to provide a clear articulate vision. I cannot sift through all the noise.

However I think this is a good thing for AI if you want a basic understanding. It can sift out the noise.

1) Summary of the concept​

Imb proposes building two generic forms (one continuous and one single-record) that act only as carriers of controls. Each control’s behaviour is defined in front-end metadata tables rather than in the form’s design or in back-end constraints. When a form opens for a given Item (e.g., "Person"), generalized code locates an Item-specific routine (e.g., Person_Open) and uses metadata to place, configure, and tag controls. Controls are tagged with A_Veld_id, and event handlers (Enter/Click/Exit/KeyDown/MouseDown) read the metadata to validate and save values; the form itself does not need a RecordSource. [See citations in the References section].

Imb’s posts emphasize that the same flexible forms and shared general library can be reused across many applications. The metadata captures field behaviour (validation, display, storage) and enables dynamic views (overview lists, selection dialogs) without relying on datasheets, cascaded combos, or mainform/subform structures. [See citations in the References section].

See rest of discussion to include code examples and metadata explanation in document.

​

 

[MajP]

Here is a very good explanation of how the OP does away with comboboxes. However, again the question is would anyone prefer this over a combox. Without seeing it in action it sounds as a less favorable UI. So again does the ease in development outweigh the less preferrable UI.
However, I can fully understand this without the platitudes and Ponzi scheme sounding language.

Concept: Selector Form Instead of Cascading Combo Boxes​

Traditional combo boxes rely on hardcoded RowSource queries and multiple event handlers for cascading. Imb substitutes a generic selector form that is configured at runtime using front-end metadata (e.g., A_Veld_tbl fields like RowSourceSQL, WhereClause, OrderClause). When a user needs to pick a value, the control’s Tag (A_Veld_id) drives the creation of a parameterized SQL statement and opens a reusable continuous form that lists candidates. The selected row is returned to the calling form, which persists the value following validation rules (A_Before_tbl) and runs post-save actions (A_After_tbl).

Workflow​

• User enters or clicks a field that requires lookup (e.g., PostalCode).

• Event handler reads metadata (via Tag=A_Veld_id): which table/columns to query; filtering and ordering.

• Build SQL string based on user input (quick filters) and metadata.

• Open reusable selector form (continuous view) and pass SQL via OpenArgs.

• User selects a record; selector returns chosen value to the caller (OpenArgs/TempVars or a public function).

• Caller writes the value to the bound record (or DAO) and applies before/after rules.

Code in attachment.

 

[Imb]

@Imb
I share the same frustration as everyone else regarding this (and previous) threads
To remind you, I am unable to test your simple example as I use 64-bit Access.

Back in post #40, you offered to send me by email an MDB version of the General.mde file so I could try it out.
However, it now 6 days later and I haven't received anything from you

I really understand all these frustrations, and where possible, I work hard to improve the code for a better understanding of the principle of Late Control Binding.
But we have not yet reached a common thinking.

I will try to explain the principle as simple and as short as I can.

When I want to start an application, I need a table.
By specifying the tablename, the table is generated in the development-db, with instructions to synchronyze it in production-db.
A table needs fields, so I can specify the fieldname, fieldtype, etc.
But the user is more interested in how the control, that represents the field, behaves in terms of business-rules. All this information is stored in a FE metadata table. In the meantime the field is added in the table with the right fieldtype, with the synchronization instructions of the BE.
An important point in the metadata table is the "control type", that is far more nuanciated then the fieldtype of the associated field.

Now I want to make a continuous form of that table.
For that I have a "generalized" form with only just textboxes, without further user information.
In the Open event of the form I can specify which controls I want to see, tag them with the right ID of the metadata table, place them in the right position, colour them if necessary, get information from the correlated fields, and the form is displayed.
So only with information from the metadata table, any continuous form can be produced, just with the same "generalized" form, independant of the table, and independant of the application.
Each control triggers exactly the same control events, and dependant on the control type, the right actions are taken. For instance, in the Enter event of the control, the control is "bound" to the metadata record, with all details how to behave, and in the Exit event the changes are stored. But all these events however, can be influenced by local conditions.
All dynamic actions on the "columns" are build in: hide, unhide, change width, change backcolor, sorting, ...

With unbound forms I can go a step further: with a number of additional controltypes: label, button, select menu, multiselect menu, ... It is possible to make dynamical calenders, schedules, genealogies, but also include any "fields", by referencing to the originating metadata record. Again, each control always triggers exactly the same events.

Many of the underlying processes in an application have already their own "module" in a shared library database. This is the basis for automatization of applications.


I hope this nutshell overview throws some more light on the topic.
If not, please ask.

 

[isladogs]

Just to say that @Imb has now sent me the .MDB version of the General file. Thanks

I will now need to go through each module converting all API declarations and related variables to be VBA7 64-bit compatible
That may take a while as there are a lot of code modules!
Hopefully I will then be able to look at the database functionality later this weekend.

When I get that far I will study the above explanation carefully!

 

[tvanstiphout]

Just to say that @Imb has now sent me the .MDB version of the General file. Thanks

I will now need to go through each module converting all API declarations and related variables to be VBA7 64-bit compatible
That may take a while as there are a lot of code modules!
Hopefully I will then be able to look at the database functionality later this weekend.

When I get that far I will study the above explanation carefully!

Peter Cole has an auto-converter.

 

[isladogs]

Yes i know. I have his free scanner but not his commercial auto converter.
in this case there are 15 modules with APIs to check / convert.