Dynamic/reusable forms

[The_Doc_Man]

Because every company's data collection method and workflow is different.

Now YOU are preaching to the choir, my friend.

 

[Imb]

It is customizable and not bloated and restrictive like many out of the box solutions which, from what the op described, is what @Imb is trying to achieve.

Hi raziel3,
Like many other in this forum, you missed the crux completely. All you people are only too overhasty in your own conclusions how this system works.
I don't have predefined forms to fit all, that would make things worser than it already is.
I have one dumb form, with only hidden controls. But I have pieces of code, both sharable over all applications and adaptive to the local context, to make millions of different appearances. Because all is done in memory, users can - within broad limits - have influense on the appearance.
It seems that nobody reaches that point, because they are too hastened to listen.

To explain the whole matter - what is important for understanding! - is too lenghty, I have experienced. People become impatient, and draw wrong conclusions, including the needfull humor/sarcasme.

If you have concrete questions, I am glad to answer, until the penny drops.


Imb.

 

[Uncle Gizmo]

It seems that nobody reaches that point, because they are too hastened to listen.

Over 40 posts in this thread!!! ---- You don't appear to be able to convey your message very well.... In your last post you give the impression that it's everybody else's fault!!!!

Don't you think you should look closer to home???

 

[Imb]

Hi Pat,

I start with a form to add a new person/relation. T

I am sorry that the program stuck.
I will continue with an example to get the right Dutch postcode depending of "some" crooked data about street and city.
You see a form to add a new Person/Relatie. This form is - behind the screen - EXACTLY the same as all other forms.
Street and city are greyed, so not user-typed, but retrieved from the postcode database.

I want to search the postcode that belongs to a certain street in a certain city. Therefore I rightclick the postcode control.
A new form, but again just the same behind the screen, appears:

Now you can choose a city, and choose from all the streets in a city, like a cascaded listbox. But then you do the work instead of the program.
You can also let the program do the work by supplying (part of) the city name and/or part of the street name. For the lazy users not willing to type much, I will type only three characters. Any possibility you can supply: beginning, contains, ending, some kind of Soundex, etc.

Pressing "Zoek" results in (about 0.3 seconds) the next form:

in which form I have already clicked on "5663 GB", because that is the one I was looking for.
Finally clicking on "OK" closes the form and fills the original "new" record:

The choosen postcode is for numbers 3-37, all odd. If I also had filled in the housenumber (5), then the retrieved set would be much smaller, and is not so interesting for a demo.
If only ONE postcode is retrieved, it is directly inserted in the new record. If no postcde is found, a message is generated that the postcode is missing. In that case the user can select a special "unknown" land to make all controls free editable.
When you fill the housenumber afterwards with a different number than in the range 3-37 odd, that number is not accepted, only the numbers in the correct range.

I hope this gives you a first example of the dynamical forms. I works for all cascaded comboboxes, because it just uses the same definitions as its Rowsources.

Please start now your (structured) questions.


Imb.

 

[Uncle Gizmo]

Please start now your (structured) questions.

Well I've never done this before, I'm going to flounce!!!!

!!! I'm leaving the thread never too return !!!!

 

[Imb]

Over 40 posts in this thread!!! ---- You don't appear to be able to convey your message very well.... In your last post you give the impression that it's everybody else's fault!!!!

Don't you think you should look closer to home???

Hi Uncle Gizmo,

Well, most of the posts are answers to the posts like yours. In fact it is a waste of effort from both sides.

But, to stay positive, I published an example as an alternative to cascaded listboxes.

Imb.

 

[Mark_]

@ Ibm,

From the description of what you are trying to do, Access may not be the best fit. You would want a more generic environment where you can have a data table for events for each field and use Object Oriented Programing for your library. This would allow you to create controls as needed instead of having to preposition them. Also avoids issues Access has with creating and destroying controls.

Have you looked into VB?

 

[Edgar_]

@Imb
I must confess I have no idea of what this thread is about, but based on the first few posts, it seems you're trying to get ideas or contributions that help you scale your currently 50MB+ code base. But instead of scaling your app, what scaled is the heat in this thread in terms of the skepticism towards the solution you're currently showing, which you say is a single form that morphs into controls and that this approach helps you maintain more than 100 applications that may or may not be different.

Question 1:
Is the summary correct?

Question 2:
What are you actually doing? Are those textboxes being created on the fly or are they becoming visible?

Question 3:
How does this approach actually help you maintain many applications?

Question 4:
Did you even try to use classes to build your forms?

Question 5:
Do you know other technologies, like HTML or WPF, do this by default and are arguably much easier to write than making this work with Access?

 

[Pat Hartman]

It seems that nobody reaches that point, because they are too hastened to listen.

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.

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.

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?

 

[Imb]

@Imb
I must confess I have no idea of what this thread is about, but based on the first few posts, it seems you're trying to get ideas or contributions that help you scale your currently 50MB+ code base. But instead of scaling your app, what scaled is the heat in this thread in terms of the skepticism towards the solution you're currently showing, which you say is a single form that morphs into controls and that this approach helps you maintain more than 100 applications that may or may not be different.

Hi Edgar_,
I really feel more comfortable in the discussions with you.
My purpose is to present a way to develop applications very fast, for non-commercial organizations, that have not the budget to buy commercial software, and don't have the expertise to make these applications themselves. To service all kind of situations the program must be extreme flexible. And here starts the poo, poo and bla, bla.

Question 1:
Is the summary correct?

I am not scaling the code base, just to scale. The purpose is to add functionality and flexibility, whatever that is.
In standard Access all is fixed around forms, that all must be defined in the development mode of the application. In my opinion they are too static, because they can't be shared between applications. And if you encounter a special case, a new form must be defined.
Through many generalizations of code I came to the conclusion that not the form is the crucial object, but the control.
In standard Access, that is also accepted, and can be handled control classes. But still the static forms are there.
In my concept the form is reduced to a carrier of controls, and the controls are tuned to their "all-in" meaning (in standard Access terms including BeforeUpdate, AfterUpdate, Exit, etc
I really hope you see this not as bla, bla, but as a different way to use Access.

Question 2:
What are you actually doing? Are those textboxes being created on the fly or are they becoming visible?

With regard to the above, "The form" (in fact I use two template forms, one for continuous overviews and one for all the rest) is tuned in detail in the Open event of the form, through generalized code blocks, and these can be shared. The controls are already there, but must be "activated". An additional advantage is that you can create in memory all kind of form-representations to suit any situation.
It is even possible that a form on the screen, can be populated by a different overview from a different application.
But it seems all bla, bla in this community.

Question 3:
How does this approach actually help you maintain many applications?

In the separate applications I have no "hard-coded" forms, but only modules with generalized building blocks.
The effects of maintenance of the code base, is immediately reflected in all applications.
I also have one specialized database (DB.mdb) that can analyze every other application, and make corrections if necessary.
Also, in the develop-fase of an application I can automate the steps of adding table, modifying tables, adding field, modifying fields, etc. This only on the base of the tablename, and an "all-in" meaning of the control to be used. One of the "all-in" properties is, where the value of the control is stored: table/Item, field, type.
Modifications afterwards are as easy. All DDL-modifications of the FE are stored, including the procedures that are necessary to do for instance a fieldtype change. This is automatically synchronized on installation of a new version.

Question 4:
Did you even try to use classes to build your forms?

That is only necessary if you have many static forms, that must handle the different types of control per form. In principle I have one "fluffy" form.

Question 5:
Do you know other technologies, like HTML or WPF, do this by default and are arguably much easier to write than making this work with Access?

That is the point I want to clarify: that it is also possible in Access, with a different look towards forms.

Parallel to these "dynamical" forms I use "dynamical" reports: general building blocks to create HTML- or RTF-files on the spot by re-use of code. But that is an other story.


For explaining the concept you must know the total concept, but also all details, because these are determining the flexibilty.
I don't believe that from the code alone you can build a true view of the concept.
A working sample database does not give more insight, because then you can add records, and modify fields, and see all kind of handy things, but don't add to an understanding.
All is already in Access, but not integral.

Thanks to your questions, I have - finally - got the opportunity to clarify a little more what this concept means.

Thanks Edgar_,

Imb.

 

[isladogs]

I have been following this lengthy thread from the start with both interest and a huge sense of frustration.
I have also seen some of your posts on other forums where I think your username is imb-hb.

As you may know I run the Access Europe User Group and am always on the lookout for innovative uses of Access that stretch the boundaries of what it can achieve. I thought initially that this topic might be an excellent candidate for a future presentation. However, over 50 posts in and I’m still utterly baffled by what this is all about.

I have long been an advocate both of reusable code and multi-purpose forms and have extensively used that approach in several of my commercial apps. For example, one of my commercial apps for schools has several multi-purpose forms used for selecting specific objects and data.

The multipurpose aspect is done using a combination of open args and controls that may be visible / hidden / enabled / disabled / locked / unlocked / moved / change caption / change use etc depending on the specific purpose / tag value.

It took years to develop and the approach works well. However, design view is a total mess with a large number of overlapping controls.

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.

This method may or may not be similar to what you are doing. I’m really not sure as, despite carefully reading the entire thread, I’m still totally unsure what your approach actually is.

Your responses to the many experienced developers who have tried asking for clarification has really explained little or nothing at all. It seems that nobody yet understands what you are describing. It seems that either you can't or won't explain the concept clearly.

Several people have expressed interest in seeing a demo which should help seeing what this does and how it works. However, you seem totally unwilling to do this. As a result, more than one experienced developer has now given up on the thread.

Your screenshots provide little in the way of clarification either.

Surely, if this is such a great idea that you hope others will take up, you would want to make every effort to help them do so.
Why are you so resistant to doing so?

Thanks to your questions, I have - finally - got the opportunity to clarify a little more what this concept means.

I really wish that were the case!

 

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

 

[Pat Hartman]

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.

This means that you don't understand at all how the expert developer works. From the time i learned to code, I was looking for ways to standardize my methods and make solutions reusable. There are patterns that you begin to recognize. List type reports have a pattern no matter how many break levels they have. Once you understand the pattern, you don't have to reinvent the wheel but it would never occur to me to make a report to support an infinite level of breaks because that is not reasonable. Most don't use more than three and I'm pretty sure I've never done more than 6.

So, I've had 50+ years of this type of thinking. I also have software solutions that I developed 40 years ago that I have implemented using different platforms over time. So, the essential logic of the solution lives on but now it is implemented in Access rather than in COBOL.

The example was to show how one can retrieve the correct value of a postcode, from uncertain information about the cityname and the streetname.

But you said YOUR method used a single form. The example showed several different forms. Were each of those forms generated on the fly using definitions found in tables? Show us that code. Tell us how you are scrolling the list without any obvious scroll bars or navigation buttons.

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.

But Access imposes limits on the size of a form so it cannot expand infinitely. I think 22" is the limit. However, if you use Access methods and bound forms, your data set can be millions of records and the sub form could show all of them, not that you would actually want to do that. Your method fails once you get past the limits of Access which size wise would probably be a hundred or so records long and about 30 columns wide and that is a very small number in the world of relational databases. With bound forms that scroll, the record number is essentially infinite but the column width is limited to 255 which is the Jet/ACE limit for the number of columns in a table. SQL Server supports more. So, at least we now know that you haven't figured out some magical way to exceed the limits imposed by the Access.exe itself. Why you think this is somehow better is beyond me but OK.

Also, you don't seem to be aware that if you use code to generate forms on the fly, you cannot use the Access Runtime engine since the Runtime engine does not support design view which you would need to enter to generate a form on the fly. So a professional developer would never generate a database object on the fly since that would limit the users to using the full version of Access and also open up the specter of the user being able to get into your code in design view.

I think there is some merit to the concept of making a tool like the Access form wizard "smarter". I can see where you can define a small number of types of control and types of data where you can standardize the way the controls function and provide basic validation code. But, I would never take this to a runtime tool. I would leave it as a developer's tool that can be used to take a table/query as input and generate a form type - single, continuous, data sheet, navigation with a lot of the necessary code already attached. Then the programmer would take over and write the code for the non-generic data types and controls which will be custom or the programmer can add custom code on top of the generated code. The question then becomes does the tie between the tool and the form end once the form is created so that once you generate the form and save it, the tool can no longer be used to modify it. I'm OK with that since it makes the tool way easier to create and avoids a lot of potential problems. As most of us have already mentioned, we do a lot of this already by creating templates. They may not be slick and therefore not really a marketable product but they serve us well by reducing the tedium of repetitive development. Class modules carry the standardization further and @MajP has posted many useful class modules. He "gets it". He's the only one who makes classes that are logical and useful because he recognizes true reuse potential. Most others who dabble with classes make the mistake of making non-reusable classes because they are so specific to their particular application that they have no generic usefulness. To be worth writing, a class must be a "black box". It always takes the same input and produces the same output. PERIOD.

My favorite example of a useful Class is one that implements custom navigation buttons. Not many people like the built in navigation control so they want to put their own "pretty" buttons on forms. Well. Once you've done this once, you shouldn't have to build it again so this is an excellent set of functionality to be a class. But a single form that serves for all cases where you need a single record form, you haven't even come close to convincing me that this is possible, let alone necessary. And based on your most recent example, you have admitted that it cannot support all forms. It has so far supported the forms you have needed to create (or you expanded its capabilities) but it can't necessarily support the forms that I need.

 

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