Dynamic/reusable forms

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

 

[Isaac]

I do understand one thing from your posts - it's 9 degrees and cloudy.

 

[Imb]

The definition table in datasheet view is too large for display, thus in a couple of steps.

First the form with all Items:

Zoom in to the fields of "Crypto":

And finally all the descriptive fields of "Omschrijving":

With this "A_veld_tbl", with a record for every field in the application, all forms with field-dependant meaning can be tuned.

 

[Imb]

An additional feature of this approach is that you can enlarge and shrink at will.
factor = 1.25:

factor 0.8:

 

[The_Doc_Man]

This is all well and good, but if I may draw an analogy: You are like a car salesman showing us all sorts of flashy features on the car, but you have yet to open the hood (some folks call that a bonnet) to show us the gerbils running as fast as their little feet will carry them on the exercise wheels. The finish, lines, and coloring of the car is all well and good, but we might want to know how it runs. And from what you have posted, we cannot see that so well.

 

[DHookom]

Would it be fair to compare this entire system as an equivalent to Access’ saveastext and LoadFromText?

 

[Imb]

Would it be fair to compare this entire system as an equivalent to Access’ saveastext and LoadFromText?

Hi DHookom,

No, absolutely not. Unless I misunderstood your question.

The entire system has evolved in a RAD-tool, using generalized code.
Just name the Application, the Items (entities) and the Fields, with for every field to data for definition table, and the application is ready. Just need the data.

What still must be added are the application-dependant forms and the reports.

By the way, what made you think to compare this system with SaveAsText and LoadFromText?

Imb.

Field-definition form:

 

[Imb]

This is all well and good, but if I may draw an analogy: You are like a car salesman showing us all sorts of flashy features on the car, but you have yet to open the hood (some folks call that a bonnet) to show us the gerbils running as fast as their little feet will carry them on the exercise wheels. The finish, lines, and coloring of the car is all well and good, but we might want to know how it runs. And from what you have posted, we cannot see that so well.

Hi The_Doc_Man,

Did you ask that question also at Microsoft, when you started with Access?

See me as an enthousiastic researcher, who drilled down the generalization path, resulting in a feasable concept.
Working now on removing the evolutionary errors, optimizing the code, and make it more me-independant.

Imb.

 

[DHookom]

Hi DHookom,

No, absolutely not. Unless I misunderstood your question.

The entire system has evolved in a RAD-tool, using generalized code.
Just name the Application, the Items (entities) and the Fields, with for every field to data for definition table, and the application is ready. Just need the data.

What still must be added are the application-dependant forms and the reports.

By the way, what made you think to compare this system with SaveAsText and LoadFromText?

Imb.

Field-definition form:

If you are building a dynamic object such as a form, I expect all the information required would be contained in a save as text file. The same could be said for the results of the database documenter. If I wanted to build a dynamic application with the definitions saved in a system table, I would start with a structure like [doc_tblObjects] created by the documenter. I believe every property of every object gets stored in this table so recreating the object would be a matter of querying the table and creating.

 

[Imb]

If you are building a dynamic object such as a form, I expect all the information required would be contained in a save as text file. The same could be said for the results of the database documenter. If I wanted to build a dynamic application with the definitions saved in a system table, I would start with a structure like [doc_tblObjects] created by the documenter. I believe every property of every object gets stored in this table so recreating the object would be a matter of querying the table and creating.

Hi DHookom,

The "form" is stored as a couple of procedures in a general module. One procedures for the layout of the form, a couple of procedures as a kind of "click event" for the different "button" controls, that are specific for the form.
Most of how these forms behave are generic over all "forms".

Imb.

 

[Imb]

I can't believe you are still engaging. He's just blowing smoke

Do you happen to wear smoky sunglasses?

 

[Mark_]

What does your proposal do that template based development environments don't offer? Does it allow some way to hook in specific code for specific requirements that are not in your general library? Looking to see if your offering more than Clarion 2.0 did when it came out.

 

[The_Doc_Man]

Did you ask that question also at Microsoft, when you started with Access?

No, because I had experience with database tools from other systems.

I asked the question because I HAVE had some experience with "automatic" systems that self-generate forms and interfaces - and that is why I remain a skeptic. I know their weaknesses.