Dynamic/reusable forms (1 Viewer)

[Imb]

I hate to say, but you TOTALLY MISSED the concept, only ventilating your own ideas.

Imb.

 

[GPGeorge]

I hate to say, but you TOTALLY MISSED the concept, only ventilating your own ideas.

Imb.

The very definition of irony.

 

[Isaac]

This is really a cluster-f !

 

[DHookom]

I would have started this thread/concept with the smallest idea of creating a single multipurpose form with a little metadata to customize it at runtime. This would have been easier to conceptualize and digest. Most of us have done something like this (as evidenced from many posts) and would follow the logic. The idea could have been slowly developed with an explanation of the ERD of the metadata and snippets of code.

Instead we got

 

[Imb]

So, what is the source object of the 20 subform controls? Is it the same form or different forms?
How does the control definitions look?

Sounds like a clever way to deploy applications for those that don't have strict specifications. So it's good.

Hi Edgar_,

Your question points to the right spot for one of the findamentals of this approach.
I will try to explain this as simple as possible. So I will drop for the moment all kind of accompaning remarks.

I have ONE flexible form to make a multitude of representations, on the spot. In fact there are two, one for the continuos case, and one for all the rest. Within my concept that makes no difference, because it is the Control that is important, and the form is just a carrier.

You referred to the form with the subform control, and I will handle that, let us call it the "Mainform".
This Mainform has 20 subform control. The number 20 is just arbitrairely. I use these subforms more or less to create columns in the representation. Each subform control can be loaded with the same "Subform", if necessary. This subform carries 66 (grown through evolution) Textbox controls, without any definition.

Before I continu I have to say the each field in each table/item/identity has a record in a metadata table, the "A_Veld_tbl", with the specification how each field-representation on the form, thus each control, should behave.
When you open a dynamical form, you must give it a name, e.g. "Person". the generalized code searchs for a sub named "Person_Open". In this sub is specified what you want to see on the form. A couple of these result is already shown somewhere in this thread.
In this sub I define where the control is placed, and specified which function it will have: representing a field in an Item, or be a Label, Commandbutton, ... If it is a Textbox, an Item and Fieldname are defined, and searched in the A_veld_tbl to catch the A_veld_id. This A_Veld_id is tagged in the control. With ths t you can retrieve the value and display it in the control. I do this for every necessary Subform.
Then the form is displayed. The form itself is not important anymore, but the Control and its Tag.

How the form is reorganised afterwards is not important, as long as the control keeps its tag. But nothing prohibits to change the tag, but that is out of scope on this moment.

Now how work the controls.

Whenever you Enter a control, its Tag identifies which A_Veld_rec must be opened, to have all the attributes for this control, but also the initial value is stored. On Exit, you can immediately identify the "Dirty" state.

In related metadata tables is described all details about validation the data in the control, and actions after changing the value of the control. All these steps are only performd if the control-value has changed.
Depending on preferences, the you can store the new value or not.

How to react after entering, clicking, dblclicking, ... is described in the general code.
If things are application dependant, the program flow is passed on to local subs, named e.g. "Person_Click".
All what is necassary are metadata-tables, shared general code, and if necessary, local code in a general module.

I hope this base-information helps you in understanding the concept.

Imb.

 

[Imb]

The very definition of irony.

I learned a lot in this thread ...

 

[Edgar_]

When you open a dynamical form, you must give it a name, e.g. "Person". the generalized code searchs for a sub named "Person_Open". In this sub is specified what you want to see on the form.

What sort of sub are you talking about? a sub routine, a sub form?

In this sub I define where the control is placed, and specified which function it will have: representing a field in an Item, or be a Label, Commandbutton, ... If it is a Textbox, an Item and Fieldname are defined, and searched in the A_veld_tbl to catch the A_veld_id. This A_Veld_id is tagged in the control. With ths t you can retrieve the value and display it in the control. I do this for every necessary Subform.

What do you mean by item here? Also, I prefer to see how the metadata looks in your Access file, can you take a screenshot or paste here a few examples of the whole definition that will be processed by your code? It's really hard to see what you're doing with just that. I understand you're using those keywords in the tag, but where are they defined? a table record? then how does that record look?

All what is necassary are metadata-tables, shared general code, and if necessary, local code in a general module.

Okay, it is a table. How does that actually look?

Here's the problem we are having. When you make a framework that you want others to use, feel inspired by, sell, whatever, we need to know what that framework is going to require us to do and see the output. Take a look at this:

Quick Start – React

The library for web and native user interfaces

react.dev

As you can see, it goes straight to the point: your code will look like this, and this is what you'll get. Period.

Nobody in a hurry is going to go check the code that is powering it, we just want to see what we will do and the result. Once we have seen results, THEN we can analyze it further in order to expand it or whatever.

 

[The_Doc_Man]

With no criticisms intended, this thread wastes my time because the words do not adequately convey the level of abstraction needed to understand what is being done and how it is being done. The product might, indeed, be the greatest thing since sliced bread - but I still don't have a taste of what it is all about.

@Imb - if you wanted open discussions, there is such a thing as quid pro quo and at the moment we haven't seen any quid.

 

[Mark_]

If the "Address" screen OP posted is any indication of where he is going, this would never work for my needs.

 

[Imb]

Hi Edgar_b,

I am trying to reply you, but the answers are blocked.
I will try lateron.

Imb.

 

[DHookom]

Imb, you are not able to post with links until after your 100th post in this site. The error message is not much help. There may be other limitations but you should be able to work around most of these.

 

[Cupet]

Hello, please, how do you envisage RealWord working? Do I understand correctly the use of only two versions of saved forms (single and continuous) which are modified appropriately using code and parameter tables when opened and linked to RecordSet?
I (like many) use unified dynamic unbound forms to display data opened as instances. This gives the application integrity and UI uniformity. But I can't imagine having an entire application based on just two forms. Of course, if the application was similar to the Palm PDA environment, it wouldn't be a problem.
I have tables in my application where dynamic form descriptions, record sets, variables for working with data, forms for editing a particular record set, filters, field IDs are defined. The fields in the tables have predefined properties, the length of the text box element, or SQL queries for the filters, so that the element is always the same in each view.
However, the application contains several such forms. The environment is similar to Outlook, with a toggle panel on the left, the main data (Products, Tech, Directory...) at the top and optional secondary data linked to the selection at the bottom. Then there are the other forms: local filters, dashboard, graphical production planning... Why should a form have all the elements if it doesn't need them? Why should a toggle panel carry a chart if it is hidden anyway and only consumes system resources?
I use about 300 text boxes for production planning. Why should they be hidden even in a form where only two elements are needed? It contains a lot of code that is not needed in a dialogue box.
Can you please make a screenshot with the generation of dynamic calendars, timetables? How does the code work with RealWord please, so I can understand your idea.
Thank you and hello

 

[Imb]

 

[Imb]

 

[Imb]

I have taken a few days for sabbatical leave, to give my mind some rest.

I experienced this thread as dominated by a couple of persons, and their admirers, that only shout without trying to understand the underlying principle.
"Throw the code over the wall, and we understand it".
I must admit, that I did not touch the right cord at the beginning.

I due time, when I have found better words, I will start a new thread with the very point that matters, as a postulate. That is the start of a discussion regarding the pro's and contra's, for a better understanding for everyone.
Only in a later stage the code starts to play a role.
Despite all the negative critics, I still believe the total concept is viable, evidenced by many applications in which I used this concept.


To bypass all the unwanted noise, you can send me a personal message.

Imb.

 

[Cupet]

OK, thanks for the screens. I think I understand the principle. You use code to format and set according to parameters stored in tables, forms, sub forms, move controls, hide unnecessary ones, react to events, set record and control sources. No problem. I just think that having just two universal forms is not enough. Data entry forms can be sophisticated to provide convenience and affectivity. They don't need to be linked to data sources, but sequences can be generated on command to add or update data. The requirements tend to be so varied that I can't imagine having them in a single form in VBA code. Perhaps as subroutines in VBA modules, but this would create confusion by increasing the requirements for selecting the actual code needed.
For displaying lists of data and query results, a universal form is fine, but one is not enough and Access will not provide users with everything it has. I may be misunderstanding this, but having VBA code in a table and running it when needed is not possible. Don't misunderstand the replies in the thread, they are based on years of experience and I'm grateful that the experts here provide their knowledge to others.
Among other things, the Outlook programmers didn't just use two forms. This doesn't mean that your work will be rejected. On the contrary, it can provide valuable input into the design of the IU environment and the subsequent VBA coding. It is clear that one change will be reflected everywhere because of the concept, just make sure that the tax is not too high.

 

[Imb]

They don't need to be linked to data sources, but sequences can be generated on command to add or update data. The requirements tend to be so varied that I can't imagine having them in a single form in VBA code.

Can you give me an small description what you mean with the "sequences"? It would help me for a better formulation of my postulate.

they are based on years of experience

Did they build up experience with "two forms"?
I shouted my "Eureka" only recently, after many years of generalization, from the start with Access2.0.

It is clear that one change will be reflected everywhere because of the concept

I don't think so.

Nevertheless, you are close, only at the very end you took the classic turn-off, instead of the next not yet paving-stoned one.


Imb.

 

[The_Doc_Man]

All you people are only too overhasty in your own conclusions how this system works.

Perhaps because we have nothing solid to evaluate so instead have to speculate.

 

[DHookom]

Imb,
It would have made sense to start with a very basic description of the high level steps/processes when a form is opened. There have been over 80 posts in this thread and we still haven’t seen any table structures or a relationship window screenshot or even if the data is stored in standard tables like an employee table with fields like FirstName, LastName, date of birth, etc.

You can’t expect support for your framework without some basic information and answered questions.

 

[Imb]

Imb,
It would have made sense to start with a very basic description of the high level steps/processes when a form is opened. There have been over 80 posts in this thread and we still haven’t seen any table structures or a relationship window screenshot or even if the data is stored in standard tables like an employee table with fields like FirstName, LastName, date of birth, etc.

You can’t expect support for your framework without some basic information and answered questions.

Hi DHookom,

I was not in the position to answer till now.

In my never ending work on generalization I realized that Forms are quite static, because they contain relevant information about the fields. By excluding this from the Forms, and transfer it to definition tables and/or general modules, you can go a step further in generalizaition, with respect to Before- and AfterUpdate events.
The Form itself is just "empty", and is reduced to one for continuous records and one for all the rest.

For simplicity, I will concentrate on a "continuous" form. It has nothing to do with how user data is stored in tables (done in the "normal" way), but only how data is displayed.
In my applications all relations are bi-directional. That means that it makes no difference with which Entity you start, through the relations you will arrive on the right spot.

I choose a neutral application with its openings form:

When I click "Crypto's" a selection form is opened, with all kind of selections on any field to reduce the number of selected records.

I allready type "code". Then press "Zoek" will produce the continuous form with all "Omschrijving" containing "code"

This works for every Entity (internally I use: Item) and is completely automatic generated. Only a definition table is needed.

I will post this reply, and continue in the next with the definition table.