Dynamic/reusable forms

[Imb]

We're not as dumb as you think we are and we have listened. All you are doing is bragging about how wonderful and flexible your solution is. Show us a form and the code that makes it so wonderful and the tables the code uses to control everything.

No Pat,
I don't think in that terms, it is nor my style. There are differences, though, because our references are different. For me from the dynamical approach, for you from the standard Access approach.
I use words like "flexible" or even "extreem flexible", but not words like "wonderful" of "ethereal", and that kind of flattering terms. These are all invented here in the forum.

You keep saying that you have a single form. Well, the form images you posted don't bear any resemblance to each other so does that mean that each time you open a form, you look up some data in a table and figure out what controls it needs and place them neatly on the form in some rational configuration which is defined by the table. Nothing you have described relates to what you are showing in the pictures.

Mostly right. It is configured in relation how the user can easily understand what he was looking for.
The example was to show how one can retrieve the correct value of a postcode, from uncertain information about the cityname and the streetname. And this was one of the results. Nothing to do with the general concept, only showing that working without cascaded listboxen is also a possibility with dynamical forms/applications.

The form that shows the post code list seems to include a subform but there is no navigation control so have you just created a matrix of controls and put 11 instances on the form? What if you need more? How do you get to the next page?

There is one dummy form for continuous records, and one dummy form for all the rest. Both are unbound.
The functional part of the rest-form is 20 identical subforms, with each 66 anonymous hidden controls. The numbers have evolved in some way. I have the choice between modifying the current form on the spotto display the retrieved record, or open an additional continuous form. For the systematics it makes no difference, because I can "spoil" forms as long as there is memory capacity. It is not a mathematical matrix.
In unbound forms there is no navigation control. You can click on it select.
When there are more "records" than the screen height can display, the form is enlarged to accomodate all records, and a scroll bar is displayed.
With large number of records you can switch to a next form that displays the data divided over more columns.
And finally, you can always ask the user to make a sharper criterion. In general that is always the best.

By the way, and I think that is the most important part: each control, anywhere in the application, refers to a specific record in the metadata table, that describes the control "all-in" from the user/design view, including where and how to retrieve and store its value.

Thank for listening.

Imb.

 

[The_Doc_Man]

My original admonition in your introductory comments still applies. If you have something to sell, this is not a marketplace of products. It is a marketplace of ideas. Your explanation of your ideas remains a bit thin in substance.

Let me take a different approach. If you have something to sell, I understand that you would not want to "show your hand" without contractual protection, a non-disclosure agreement or something like that. However, at the moment you sound more like a marketeer than a software engineer. Are you actually planning to sell this "thing" you have developed as a product on the open market? Do you plan to continue developing closed "turn-key" systems where the overall system is the product but using your methods to more rapidly implement?

I understand if you are reluctant to show more of what you've got because you are trying to protect your investment. I am the same way about my novels. (Still on-and-off trying to find a publisher.) So... are you trying to balance this discussion against your fear to publish details?

Here is the fly in the ointment: You have now described a wondrous method/product to a bunch of technical skeptics who have, collectively among them, a few HUNDRED years of experience in projects. If you include my pre-Access projects using other development environments, I have maybe forty years of directed projects including both base product development and specifically targeted projects built to a customer's specifications. Multiply that by a few dozen members and realize that you are dealing with folks who have already dealt with customer reality a lot. You aren't really "wowing" the audience. The crowd is getting unruly.

Understand, we respect your need to protect YOUR product. But in a way, when we remain skeptical of your claims and call you down on things you have said, WE are protecting OUR product, which is the Access World Forum as a place where people can get decent help with their problems. As part of our method of protection, we feel it is in our best interest to interrogate and challenge people trying to push some product of unknown quality and effectiveness. Which, at the moment, includes whatever it is that you have been talking about in the last 50 posts.

 

[The_Doc_Man]

Now a more specific comment: In your post #54 you talk about dynamic configuration. Do you have a bunch of pre-defined but hidden controls or do you create your controls when you (or your code) configures a form? Because there is this little "gotcha" that Access has a life-time limit on the number of controls that can be created on a form. Dynamic control creation would seem likely to run into that limit quickly after several days of use, so you have to have a bunch of hidden, re-usable controls - or else you dynamically create and drop forms to reset their capacity. Which implies, for Access as a platform, frequent Compact & Repair requirements.

The reason I remain seriously skeptical is because a corporation the size of ORACLE, after they bought out PEOPLESOFT, was unable to generalize the U.S. Navy's personnel management system using their "library" of pre-defined data types. They had to resort to "PEOPLECODE" to do a lot of what they claimed they could do, and the problem with PEOPLECODE was that they claimed it wasn't code, it was data. Except that it really looked like code to me. But what did I know? I was only a PhD with experience in several different disciplines and an analytical mind, watching the train wreck that it turned out to be.

The inherent flaw (so far) in ALL systems that claim some special dynamic reconfiguration ability is the injection of the unknown or unusual, with a customer who ABSOLUTELY refuses to let "the tail wag the dog." The Navy would not allow PEOPLESOFT to say, "Well, maybe you should change the way you do business." Heck, it takes an act of Congress (in some cases quite literally) to change even the most minor procedure. This led to an innumerable list of customizations that cost more than the base product.

When the Dept. of Defense tried to use PEOPLESOFT for their ill-fated DIMHRS project (you can look it up in Wikipedia), there was no uniformity of personnel management among the (then) five branches of the military - AND it was worse for each branch's reserve component. For instance, U.S. Navy Reserve sailors are under contract; they are not treated the same way as Army Reserve or Marine Corps Reserve. Therefore, there was no path of reconciliation to get it all into a single database. The project's internal overhead and the repeated failure of the servers to be able to process 24 hours worth of transactions in under 24 hours of run time eventually killed the project.

 

[raziel3]

Similarly, each additional usage becomes increasingly complex and difficult to troubleshoot. Eventually, I reached a point where it was taking up more time to maintain than the amount of time it was saving and called a halt.

@Imb this statement has a lot of significance. I DO NOT want to discourage you at all in achieving your goals but when I was younger and started out development I too wanted to create a well rounded database solution to fit any and all needs. The problem is that every time I implemented something an new need would arise and I have to go back to the drawing board to make 'updates'.

After years in the corporate environment I realized that getting dynamic and reusable objects to work requires a lot of time to maintain. For example take Sage. It is one of the best accounting software out there and it suits almost all business needs but it still have limitations, it is not good at visualizing data. Someone would have to extract the data into Excel or Power BI to make a proper presentation.

What I am getting at is Sage is a company with about 1000 employees working together to make the software work and taking on a project like this needs people collaborating but in order to collaborate well and bounce ideas of one another, a working or somewhat working template is needed to make the necessary suggestions to move the project forward.

 

[Edgar_]

@Imb
I think I understand what you're doing. Basically, your framework lets you write the control definitions to a table and after that everything is handled by the forms.

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.

 

[Isaac]

This "lmb" person distinctly reminds me of someone - but I can't remember the name - who got banned from UA for going on and on ad nauseum using a lot of words without really saying anything and arguing with members. Just the tone seems very familiar, and the going on and on with pages of writing and at the end having said nothing. If I remember the handle I'll post.

 

[Josef P.]

Quote from post #1:

Now finally my question. I am looking for developpers that work in the same area, to share ideas, and to improve the whole process, or articles that cover the same approach.

I don't know why some posts talk about advertising for the marketing of a framework. From the quote above, I understand that you want to share ideas about the design. Am I wrong about this?

As already written in #36, I also use forms from time to time that provide (show) dynamically required controls. However, these forms always have a specific task for me, they just look different or have different control source. Example: Attributes of an article that are different depending on the article group (different names, look-up data, etc.).
If I want to react to an event for an attribute, I intercept this in the form and use the attribute code to check whether something should be done.

Private Sub txtAttributeValueTxt_GotFocus()
 
   Dim AttributeCode As String
   Dim ...
 
   AttributeCode = Me!fiAttributeCode.Value

   If AttributeCode = "ProductionLock" Then
       ' (open dialog form to select lock state, description, ...)
       ....
   ElseIf ....

This is sufficient for my case, as the number of attributes is manageable.
This would be nothing for a generally usable form.
How do you design this in your form?

 

[Imb]

Quote from post #1:

I don't know why some posts talk about advertising for the marketing of a framework. From the quote above, I understand that you want to share ideas about the design. Am I wrong about this?

Hi Josef,

You are absolutely right! That is the only point.

I agree that a video would have clarified a lot, but I have no expertise to make video.
And publishing an example database: the most important part is the generalized code to make it dynamical.
You must have quite an experience in reverse engineering, to understand how it works.

In a few moments I start an answer to another post, a post without all those cumulated emotions. Perhaps that is also interesting for you.

Have a nice day, Imb.

 

[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