Dynamic/reusable forms (1 Viewer)

I do understand one thing from your posts - it's 9 degrees and cloudy.
 
The definition table in datasheet view is too large for display, thus in a couple of steps.

First the form with all Items:
Schermopname (97).png


Zoom in to the fields of "Crypto":
Schermopname (98).png


And finally all the descriptive fields of "Omschrijving":
Schermopname (99).png


With this "A_veld_tbl", with a record for every field in the application, all forms with field-dependant meaning can be tuned.
 
An additional feature of this approach is that you can enlarge and shrink at will.
factor = 1.25:
Schermopname (100).png


factor 0.8:
Schermopname (101).png
 
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.
 
Would it be fair to compare this entire system as an equivalent to Access’ saveastext and LoadFromText?
 
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:
Schermopname (102).png
 
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.
 
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.
 
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.
 
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.
 
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.
 
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.

Hi Mark_,

I have no experience with Clarion 2.0, so I cannot answer that.

The "template" that I use is not a "standard template", it is just a bag full controls.
Schermopname (104).png


After definition (the layout) most off the control-events are handled in the general library. These are the regular events of a standard Access form. What is NOT handled by the general library, can be handled by procedures in the module of the form itself.
So, it is no hotchpotch. The module handles the field-specific things (layout, specific Before- and AfterUpdate events), all the rest that could be generalized, is in the general library. And many Before- and AfterUpdate events CAN be generalized, if you look at the processes.

One example is the automatic filling of Street, City, ... after supplying a Postal Code. IF you have a PostalCodeDatabase (for the right country), you can do it. Even the other way around: I have (part of a) Streetname in (part of a Cityname): What is the PostralCode.
Other processes: Validate EBAN-numbers, Telephone-numbers, ...

When such a module is placed in the application itself, it is local to the application.
If you move this module to the general library, it is available in all applications.

Imb.
 
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.
Hi The_Doc_man,

It is good to be skeptic.
Personally i would not speak of "automatic" systems that self-generate forms and interfaces.

I like more the "re-use" of as much as possible.

Imb.
 
So far, nothing you have described requires the level of complexity required to implement your methods. You can create standard code modules for all common types of data such as addresses and dates. You just call them rather than build the forms on the fly. Access is NOT an environment where I would ever build forms on the fly. You are essentially giving Access, the best RAD tool ever, the middle finger and saying I can do it better. Well, "better" is in the eyes of the beholder. I prefer to use my tools for their intended purpose. When my husband and I moved into our first house, we had one tool. A screwdriver. So Chris used it to drill a hole through a kitchen cabinet to run the water line to connect our fridge to the cold water. A drill would have taken about 30 seconds. The screwdriver took close to an hour.
 
Basically, what you have shown us is all flash and no content or substance - at least, from our viewpoint. You may think otherwise, but carefully note the kind of responses you are getting. I wish you no ill whatsoever, but I got more content out of a religious dialog with Aziz Razul over the merits and demerits if Islam than I have gotten from this thread.
 
I have a multi function form that by passing a recordset (DAO, ADO or value list) and a couple of parameters can be used as a multi select dropdown, an input box, a message box or used as a subform. It can also display a selected section of an existing form (I call it a quick view) by tagging controls in that form to be displayed.

But I consider it to be a tool to be used when required, not a completely different way of managing data
 
Hi Mark_,

I have no experience with Clarion 2.0, so I cannot answer that.

The "template" that I use is not a "standard template", it is just a bag full controls.
View attachment 118312

After definition (the layout) most off the control-events are handled in the general library. These are the regular events of a standard Access form. What is NOT handled by the general library, can be handled by procedures in the module of the form itself.
So, it is no hotchpotch. The module handles the field-specific things (layout, specific Before- and AfterUpdate events), all the rest that could be generalized, is in the general library. And many Before- and AfterUpdate events CAN be generalized, if you look at the processes.

One example is the automatic filling of Street, City, ... after supplying a Postal Code. IF you have a PostalCodeDatabase (for the right country), you can do it. Even the other way around: I have (part of a) Streetname in (part of a Cityname): What is the PostralCode.
Other processes: Validate EBAN-numbers, Telephone-numbers, ...

When such a module is placed in the application itself, it is local to the application.
If you move this module to the general library, it is available in all applications.

Imb.
Validating fields against a postal database and having relevant fields filled was something I could add a template for 30 years ago. Bonus was I could use one template and have it do the validation for any nation's postal database I had access to.

From what you have described, I don't see any benefit over the built in wizards that Access has. If you are interested in a very robust system that allows programmers to code ONLY exceptions, check out Clarion. Bonus is you can literally check a box and your application becomes an interactive webpage.
 
Bonus was I could use one template and have it do the validation for any nation's postal database I had access to.
That's not a bonus. When you need to have If statements in a "common" piece of code to determine what code to execute, the code is not actually "common". That is the programming style that leads to random bugs when a small part of "common" code gets changed.
 

Users who are viewing this thread

Back
Top Bottom