Dynamic/reusable forms (2 Viewers)

[Imb]

New to this forum, triggered by a thread, but alas I cannot find that thread. So I will sketch my situation.

Since long I work on generalization of code to make programs more powerful and robust. Code must be as structured as normalized data.
This has resulted in automation of many of the processes that play a role in data-handling, condensed in general routines.
For instance, the looping through recordsets. In my case I use a function "Active_set" that includes all what is necessary to run the loop, including all necessary error handling. And, because it is a loop, includes a number of progress-meters to monitor the proces, if you want that.
Another example is the complete automatic generation of an "Overview form", a continuous form for any table/recordset: no Datasheets anymore!

Another goal was that a Control should behave always the same, independant on which form or how it is used. This is, among others, prominent with controls that are filled by hand or by code, but need an Afterupdate treatment. Alas, there is no Afterupdate event after automatic filling the control.
In fact, "independant on which form" means that the form is not a substantial part of data-processing, but just a carrier of controls.

But how works Access? You define Fields with a certain datatype. These fields are used to define controls on a form, but only with the technical description of the control (type, maximum length, ...), not with the conditions of Realworld-controls, including their variability and boundary conditions. All that kind of information is hidden all over the database in Beforeupdate and Afterupdate events, in the BackEnd for Referential Integrity, etc. It makes the form static.
You can revert this process. You can define a Control, a RealWorld control, that completely describes the dynamic behaviour of that control.
That can be collected in a metadata FE table. One of the fields in this metadata table is where the value is technically stored in what type.
The controltype of these RealWorld controls may be different form the fieldtype of the corresponding field. Think of BankAccountNumbers, SSN, or worldwide Telephonenumers for validity-check. Incomplete historical dates that can be sorted. A contiguous numeric list that must stay contiguous.
But also the FK-control: this is the start of a complete dynamic walk through your application.

As I said, the form is just a carrier of controls, but can join controls together, both technically and (cosmetic) optical.
But that also means that you can tune such a form at will, depending of what you want to see. They are completely tunable to make a Singlerecord form, a Selection form with all possible selection to construct a Where-clause, or define any ordening. Dynamic Calenders, Timetables, Colour selection, Internet grabbing, ...
The tuning of such a form is by standard routines in general modules.

On this moment this is not a dream any more. I realised some 100+ applications, from easy to very complex, all with the same form for continuous records, and one for all other displays. Maintenance of all these application is no problem at all, since the definition of the RealWorld control is in FE tables, and all code in (accessable) general modules.

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.


Imb.

 

[The_Doc_Man]

I used an approach a little bit different from yours but with the idea of improving efficiency.

I built a "template" form that had a lot of controls and events already partly implemented, lacking only the detailed controls to be bound to a recordset. But commands like CLOSE, UPDATE, DELETE, CREATE, SAVE, UNDO, plus a HELP and a FILE REPORT button. Then I had events that, for bound forms, would verify that you actually used the SAVE button, for example, rather than trying to close a form and use an implied SAVE action. I had special form control modules that allowed me to apply "state" rules - like "Clean" "Dirty" "New" "Error" and a few other states. By making one template form and just copying it and then customizing the copy, I estimate I saved anywhere from 40% to 60% of the work that I would have had to do if I did each form individually.

I stayed away from any attempt to automate data handling based on what the data represented. I've watched what happens with products like PEOPLESOFT that use "data driven" programming. (See also project "DIHMRS".) The problem with those data-driven things is that as soon as you decide what data you have, someone says, "Oh, by the way, that particular element requires special handling due to regulations that differ from one nation to another."

We had a system at one place where I worked that used data-driven techniques. But we ran into the problem of "special cases" so many times that our library of classes was huge. We did oil-and-gas pipelines. We had 24 customers that wanted that feature. By the time the 24th system rolled out the door, we had 25 methods... 1 for each of the 24 customers and the 1 we originally envisioned. So data-driven methods CAN be a bit difficult to manage.

Now, let me add a comment of a different type here. I'm sure you put in a lot of work on this. Many of us have done something like you describe, to one degree or another. If you find like-minded folks to join you in your project, well and good. If all you want to do is talk technically about approaches, we're all for it. Just remember, don't try to actually SELL anything here because we don't allow that. Our site owner must approve any sales advertising.

 

[Imb]

I used an approach a little bit different from yours but with the idea of improving efficiency.

I built a "template" form that had a lot of controls and events already partly implemented, lacking only the detailed controls to be bound to a recordset. But commands like CLOSE, UPDATE, DELETE, CREATE, SAVE, UNDO, plus a HELP and a FILE REPORT button. Then I had events that, for bound forms, would verify that you actually used the SAVE button, for example, rather than trying to close a form and use an implied SAVE action. I had special form control modules that allowed me to apply "state" rules - like "Clean" "Dirty" "New" "Error" and a few other states. By making one template form and just copying it and then customizing the copy, I estimate I saved anywhere from 40% to 60% of the work that I would have had to do if I did each form individually.

I am not suprised that it did not work as you would have expected.
What I understand,is that you use a template form, and then "reform" a copy of the form to a new form. And continu to work in the old classical way.

I stayed away from any attempt to automate data handling based on what the data represented. I've watched what happens with products like PEOPLESOFT that use "data driven" programming. (See also project "DIHMRS".) The problem with those data-driven things is that as soon as you decide what data you have, someone says, "Oh, by the way, that particular element requires special handling due to regulations that differ from one nation to another."

Automating data handling is something else than automating processes for data handling.
I have an pretty large application to describe the history of a middlesized town. It contains describes the people (including genealogy) but also all kind of "objects", like buildings, streets, organizations, industry, sporting, you name is. Including all inter-relations.
Most of the data is incomplete, many times originating from different sources. So it can happen that two, or three, persons seem to be the same person. I have a standard routine that can combine the duplicates, after validation to one person again, including all relations to other entities in the database. A standard routine means that is build-in in any application, for every entity. That makes it powerful.

We had a system at one place where I worked that used data-driven techniques. But we ran into the problem of "special cases" so many times that our library of classes was huge. We did oil-and-gas pipelines. We had 24 customers that wanted that feature. By the time the 24th system rolled out the door, we had 25 methods... 1 for each of the 24 customers and the 1 we originally envisioned. So data-driven methods CAN be a bit difficult to manage.

Again, I suppose you took the non-flexible road that is build in standard Access.
Let us look at a field to store a telephonenumber, stored in a Text-field. Everywhere where you have to duplicate the checks for a telephonenumber.
I don't work with fields, I work with RealWorld controls, placed somewhere on any (anonymous) form. In the description of the RealWorld control you even can see in which field the telephonenumber will be stored, but that is a minor thing. More interesting is what you want to do in the Real World with this telephonenumber. So as soon as you enter a control on a form, the program knows the description of the RealWorld control, and knows the module where to find all information on telephonenumbers. This telephone module is general to all applications, and can be easily extended to add functionality.

Now, let me add a comment of a different type here. I'm sure you put in a lot of work on this. Many of us have done something like you describe, to one degree or another. If you find like-minded folks to join you in your project, well and good. If all you want to do is talk technically about approaches, we're all for it. Just remember, don't try to actually SELL anything here because we don't allow that. Our site owner must approve any sales advertising.

I know. My goal is to understand and improve.


Imb.

 

[Pat Hartman]

Access objects are already reusable. They are powered by Class Modules. That is the point. MS has thousands of lines of code that runs behind the scenes to ensure that Access objects are reusable. You are taking this to another level using code and I believe that to some degree, that is over reach. If a bunch of forms do the same thing, you almost certainly should be using a single form for which you replace the recordset which is the simplest way to reuse the form object.

Alas, there is no Afterupdate event after automatic filling the control.

That is correct. You are using a RAD (Rapid Application Development) Tool and it is doing a whole lot of stuff for you.

Think of the events attached to forms/reports/controls as hooks. MS Access runs the main line application code and provides "hooks" at specific places where YOU can add additional code that handles specific tasks whenever that event is triggered. No matter what you think, you are NOT in control of form logic. Your job in Access is to understand the event model so you can place your task specific code into the CORRECT event.

I stayed away from any attempt to automate data handling based on what the data represented. I've watched what happens with products like PEOPLESOFT that use "data driven" programming.

This has been going on since the dawn of computing. There are a number of large "we do everything" applications that cost hundreds of thousands of dollars per year which provide certain types of customization options. What I have found is that like my cell phone, these "we do everything" apps, may do everything but they do nothing well. I've made hundreds of thousands of dollars over many years writing both COBOL and Access applications to fill the gaps in these monstrosities. SAP was the worst. It was written in German when COBOL only supported 8 character field names so no variable name made any sense at all. It was the proverbial fricking nightmare to program for since you never knew with out a translation list, what any field contained.

Seems like you're on the SAP track. Good luck.

Again, I suppose you took the non-flexible road that is build in standard Access.

Access is a RAD tool designed SPECFICALLY for a certain type of data-centric application. If that is the kind of application you are building, there is nothing faster or easier to use. Everything common is already automated for you although you may not approve of MS' choice of what that automation does, like your complaint that certain events are not triggered when you populate controls using VBA rather than via typing. I'm pretty sure the logic was that the user types and needs to be protected from himself but the programmer knows what he is doing and doesn't need that protection. However, as you may or may not have observed, the Form's BeforeUpdate event ALWAYS runs when the form is dirty. Think of that event as the flapper at the bottom of a funnel. When the flapper is open, Access saves the record. When you close the flapper using "Cancel = True", Access does not save the record. That event is where the ultimate control resides.

Let us look at a field to store a telephonenumber, stored in a Text-field. Everywhere where you have to duplicate the checks for a telephonenumber.

Only if you don't know how to write a function or a procedure and call it. What Access does is it gives you the "option" of validating the phone number. You only repeat the code everywhere if you don't know any better. Your approach removes the option and forces the issue OR you need to define a special phone number control that uses different rules. For simple rules, you may be able to use Validation rules on the column in the table.

I have lots reusable code. For example, if my client doesn't like the built-in record navigation controls, I use custom controls but there is only one code procedure that is called from each of those controls (which are copied from a template form). Many people take this even further and make the common code an add-in. The reusable code is quite simple, it takes either the form object or a control object as an argument and does its thing. Although it is generally poor practice to have multiple forms that update a single table, sometimes, the client needs it to happen. So, I place all the common validation in a procedure that is called from the BeforeUpdate event of the form. So form 1a and 1b have common validation done with ONE procedure but 1a has ALL the fields and 1b only shows some of the most frequently updated fields so 1a has additional validation in the Form's BeforeUpdate event. As you might surmise from these comments, I almost never use the control's BeforeUpdate event to validate anything. I look at the form as a whole rather than looking at the parts in isolation. How I validate BirthDT is different from how I validate DeathDT and both are different from how I validate InvoiceDT so, I'm not sure how having a control that validates dates helps. I can call common procedures for common aspects of the validation if that makes sense and still have custom code for the custom rules. Remember, Access is already validating the date for the basics when a control is bound to a datetime data type field or if you specify a date format for an unbound control. So, I don't have to do what I needed to do in COBOL which was to validate the year, month, and day separately and together (Feb 29 is not valid except for leap year) to ensure that the entry was actually a valid date format and then validate the date for conformance to the business rules.

I also use data driven processing whenever I can but there is a point of diminishing returns. When your "common" code includes case statements to determine how to handle something, it is no longer "common" and should not be treated as such.

As Doc pointed out, the biggest failure I encountered from my mainframe days was the attempts to encapsulate data. I was working in Corporate America during many years of change/evolution. We went from ISAM to VSAM to IMS/and many other types of database organization to DB2 (for IBM) and once the RDBMS was established as the database winner in the middle 80's the RDBMS could be DB2, Oracle, Sybase, Postgre, SQL Server, etc. The step between VSAM and RDBMS was the tough one since all the database applications worked completely differently and so there we pushes in many of my client companies to make an ODBC-like intermediary. There was no common ground. At least RDBMS standardized on SQL and although each manufacturer used a custom dialect on the language base, they were all easy enough to translate from/to. Access took that to a higher level by using ODBC so that from the perspective of Access, as long as you used the "Access way" of linked tables and querydefs, the actual BE database was pretty much transparent. My exact same code/queries would work on SQL Server, Jet/ACE, or Oracle or any other ODBC compliant RDBMS. This was HUGE in my book having lived through the data base wars of the 70's and 80's. ODBC succeeded where all the custom attempts between VSAM and RDBMS failed.

You are trying to make operating on my payroll table identical to operating on my inventory table. Good luck with that.

 

[The_Doc_Man]

I am not suprised that it did not work as you would have expected.

Ah, but for the case I was describing, it DID work EXACTLY as I expected. My comments about data-driven programming were another project. The problem with data driven programs is that to make them work economically, you have to have uniformity. Something I learned a LONG time ago is "One size DOES NOT fit all." The world is full of customers like roving dogs that hike their legs on every tree and fire hydrant so that THEIR smell (and therefore, their territory) is marked. And every one of them has just a little bit of a different stink.

What I understand,is that you use a template form, and then "reform" a copy of the form to a new form. And continu to work in the old classical way.

Yes, but for 40% to 60% less effort, since all of the common procedural infrastructure was partly or completely handled by the template. The difference between 40% and 60% was how many bound controls were needed. Simple forms? Saved 60%. Really busy forms? Saved 40%.

Again, I suppose you took the non-flexible road that is build in standard Access.

Nope, in the specific case I mentioned that prompted your particular response (our pipeline leak detection algorithm), we used PDP-11 Assembly Language. Don't think you can get more flexible than that.

The problem is ALWAYS that the customer is always right (even when he's a flaming idiot.) One reason our PEOPLESOFT project fell apart is because the military folks want things THEIR way no matter what your best business people said was logically correct. (Not the only reason.) What ran up the price tag for the U.S. Navy project was (a) customization / retrofit of the "data driven" stuff for just about EVERY data type in their repertoire, (b) their claim that data location was flexible at run-time, and (c) the dynamic nature of data-driven software often leads to datatype interpretation at run-time (as opposed to hard-compiled code) and that adds a layer of execution overhead - for which the net result of that dynamic data resolution was a machine meant to process 24 hours of business but that never could complete that processing in less than 28 hours. And we ran that stuff on dedicated UNIX mainframe-class equipment. Still was too much because of the dynamic nature of deciding what to do when and where.

 

[Imb]

You are trying to make operating on my payroll table identical to operating on my inventory table. Good luck with that.

Hi Pat,
Thank you for your answer. Quite long, and it will take some time to consume all your comments.

My first reaction was that you needed to get rid of your frustrations from how is was in earlier days. But in a second thought you are right from your point, but it missing my point.

First a question. Have you ever build over 100 Access-applications and manage these applications at the same time?
Your arguments seem valid for me for a few stand-alone applications.

Now let us try to see it from my side.
I quoted you last remark, because that is a nice starting point.

Yes, from a data point of view, I operate your payroll table identical to your inventory table.
They are both tables containing records, build up with an ID, a couple of other fields, and - occasionaly - some FK's.
The FK's refer to other tables containing records, build up with an ID, a couple of other fields, and - occasionaly - some FK's.
So, the underlying processes are just the same. But the behaviour of the fields is not the same!
A couple of the differences of the fields are layed down in the field definitions, but that is only how - technically - the data is stored.
All othere user-differences, that is how the user interprets the properties of a RealWorld control, are defined as events in the forms (and probably on some other places).
My point now is, you can define these user-differences in metadata-table. Then all these user-differences between controls do not need any more be stored in forms. Forms reduce themself to carrier of controls, and can be made anonymous. A form then is just one big variable that can be tuned in countless variations. The definition of any of the variations is standarized code that can be shared over all applications.

Because of this approach - one form and variable code - you can realize almost anything. It is no problem to change the active form to a complete different appearance. Even show a different overview from a complete different application.
In the way I use this concept, many standard Access utilities are not used anymore, such as the Ribbon, listboxes, splitted forms, the main form-subform systematic, and many other.
I agree, it is completely different from what you are used to. But what you gain is that you can make ad hoc a new "form" to make anything to make it easier for the user.


Imb.


Imb.

 

[Imb]

Yes, but for 40% to 60% less effort, since all of the common procedural infrastructure was partly or completely handled by the template. The difference between 40% and 60% was how many bound controls were needed. Simple forms? Saved 60%. Really busy forms? Saved 40%.

Hi The_Doc_Man,

You can also read my answer to Pat Hartman.
The way the different fields (controls) must be handled isd in your way: By the template.

My point is, bring it to a metadata-table, And free the form from any user-interpretation.
In that case a "form" is a "template" tuned by a piece of sharable code, mostly generalized to building blocks.
The form becomes just a carrier of controls, that can result in countless representations for almost any purpose.

As an example an genealogical family. Clicking on any person makes that person the central one.

Or an actual internet grabbing of actual valutas.

Imb.

 

[The_Doc_Man]

In that case a "form" is a "template" tuned by a piece of sharable code, mostly generalized to building blocks.
The form becomes just a carrier of controls, that can result in countless representations for almost any purpose.

The amount of time to be spent in generalizing the infrastructure has to be balanced against the amount of time to be spent in delivering a customer's finished, working product that also meets his specifications. Out of curiosity... in your many delivered systems, how many of them were for a government entity or agency? (And for which governments?) If you try this approach with the U.S. Navy you will find that they actually DO believe that one size fits all. But it won't be the size that you offered.

 

[Uncle Gizmo]

Another goal was that a Control should behave always the same, independent on which form or how it is used.

With the aid of ChatGPT I built some code for managing a standard set of command buttons for navigating through the records on a form or even a subform displayed on a main form... In the video below I demonstrate the use of the buttons on a main form....

It's an interesting demo because there's no code in the form for the buttons there's not even a code stub for the buttons!

Everything is managed through the agency of a factory module & navigation class module.

You can see more in this video:-

Next Previous Quit - Nifty Access​

 

[AHeyne]

You can define a Control, a RealWorld control, that completely describes the dynamic behaviour of that control.
That can be collected in a metadata FE table.

So your real-world controls are virtual controls whose properties and behavior you define in tables and implement in Access controls when loading a form, for example?

Or have I misunderstood you? Can you explain your idea in a little more detail?

 

[Imb]

So your real-world controls are virtual controls whose properties and behavior you define in tables and implement in Access controls when loading a form, for example?

Or have I misunderstood you? Can you explain your idea in a little more detail?

Hi AHeyne,

I am very happy with your question.
To begin with, I am not inventing something new, but look at the things in a different way.

When you use an Access-application, you normally see a Form with Controls, e.g. a Postalcode control.
But what the user/developper expects is far more than just that control. All those expectations together I have named a RealWorld control.
It is not an object, it is the complete description how the user wants to "use" that control.
Yes, all is already defined: stored and retrieved in the right Field, all BeforeUpdates are dedfined. all AfterUpdates are defined, the typography or masks are defined, editing or not, hidden or not. Most of these proporties are defined in the Form, some in the data-definition of the Field, and some (think of Referential Integrity, Keys) even in the BE.

It is important to realise the difference between the RealWorld control, and its use as a Control on a Form. Perhaps there is a far better name to describe the RealWorld control.

As many of the RealWorld control properties are layed down in the Form, the Form becomes "static", not sharable, especially not from application to application.

I skip for the moment how the metadata tables for the RealWorld controls are filled.
Starting point is the Item (or Entity), with a short but self-explaning name. An Item is stored in an Item_tbl, that has always an Item_Id as record-indentifier (Autonumber). With this simple definition you can already automate basic processes to a far extent, with just the Item as parameter.

When a form is opened (I could better say The Form, with a nickname for identifiction) the Open event of the form calls the <nickname>_Open routine. The form itself has a number of hidden controls, systematically named.
In the Open routine controls are placed where wanted and made visible. The controls that will represent a RealWorld-control get the Id of the metadata-table in the Tag-property, and are thus "bound".
Every time a bound control is entered, then the corresponding metadata-record is opened, so all information about the RealWorld control is available. During the editing process of a control you are already warned for key-violations, exceeding limits, syntax errors, ...
Saving is no problem, since the current metadata-record is bound, and "knows" where to store the data. It only takes a one-liner to do the actual storage.

So a Form is "The" form with a couple of definition routines, among others the Open routine. These can be placed in the modules of the application itself, or in a shared library database for use over all applications (ever dreamed of sharable forms?).


In time, other questions of how things work, can follow.
Or more detail, if this "little more detail" seems too little.


Imb.

 

[theDBguy]

@Imb I could be wrong but my understanding of what you're describing is you have a "generic" form that can be used for any situation. If so, I am wondering how you are managing to do that. For example, if the situation requires the use of two cascading comboboxes, can this generic handle that? What about another situation that requires three or four of them?

You shown us some images of your forms in action. Would you mind showing us the Design View of your generic form? Assuming you pre populated it with a lot of controls, how many did you use? How did you decide on that amount?

 

[The_Doc_Man]

First and foremost, if you have the imagination and some time on your hands, you can make a form do almost anything. For example, I once made a form that symbolically simulated the orbits of several planets around a central sun by moving small controls around a big detail area. It's a long story and at that time, I actually DID have too much time on my hands, helping my mother through her final days and going home to take my mind off of things. But the point there is that you have to write a LOT of complex code to be so generic and yet so flexible. Which means that your form full of "RealWorld" controls is carrying a LOT of baggage. Somewhere along the line you will have to modify something because the real world impinged on your creation and showed you where in some obscure way it was incomplete. Maintenance in the presence of all of that implied baggage would seem to be a nightmare. And yet if you claim that such maintenance doesn't happen, THAT is where I begin to doubt, because the real world is not a smooth, blank canvas. It is rough and rocky, with many features over which one could easily trip. (Speaking figuratively, of course.) There is also the limit of lines of code in a module which would force a lot of "divide and conquer" approaches. The number of "decision points" in that kind of code would be tremendous.

I'll say this: I hope that nothing breaks on you, though part of me says that it is inevitable.

 

[Imb]

Hi theDBguy,

I can "proudly" say that I don't use comboboxes nor cascading comboboxes.

The underlying data decribes always the relation between the "cascading elements".
Instead I define an sql-string that joins all these relations.
When I open "The" form I first open an (generic!) Search form where the user can make his selections on any field in the sql-string. The result with the composed WHERE clause is presented in a (generic) Overview form, defined as Selection form.
A Selection form returns one ID of a certain Item, or none.
A Selection form can even be extended, using any FK, to gain more information from other related tables, to make a better choice.

The number of controls is indeed limited. When to many records are selected (not relevant however for continuous records) I ask the user to make a better preselection, because it is a waste of time that he must "manually" work through that bunch of records. Let computers do that. A alternative that I also use, is to split lengthy values in multicolumns.

Don't look at the Design View. It is boring dull.

Imb.

 

[DHookom]

I have read Imb’s posts promoting this “world” for years with very little value as an answer to any OP question. Perhaps this forum is more appropriate. I would be more interested in the data and table structures behind the functionality. I expect every one of us have stored some design/logic in tables of our projects. This allows users to customize interface and functionality without paying more contract hours.

Show me the beef (ERD).

 

[theDBguy]

@Imb Thanks for indulging my curiosity. As I thought, your generic form is pre populated with some controls. I was wondering how you decided how much of each control to put on your generic form. For example, I see a few Checkboxes, is that enough for "all" situations?

 

[Imb]

First and foremost, if you have the imagination and some time on your hands, you can make a form do almost anything. For example, I once made a form that symbolically simulated the orbits of several planets around a central sun by moving small controls around a big detail area. It's a long story and at that time, I actually DID have too much time on my hands, helping my mother through her final days and going home to take my mind off of things. But the point there is that you have to write a LOT of complex code to be so generic and yet so flexible. Which means that your form full of "RealWorld" controls is carrying a LOT of baggage. Somewhere along the line you will have to modify something because the real world impinged on your creation and showed you where in some obscure way it was incomplete. Maintenance in the presence of all of that implied baggage would seem to be a nightmare. And yet if you claim that such maintenance doesn't happen, THAT is where I begin to doubt, because the real world is not a smooth, blank canvas. It is rough and rocky, with many features over which one could easily trip. (Speaking figuratively, of course.) There is also the limit of lines of code in a module which would force a lot of "divide and conquer" approaches. The number of "decision points" in that kind of code would be tremendous.

I'll say this: I hope that nothing breaks on you, though part of me says that it is inevitable.

Hi The_Doc_Man.

Well, the "RealWorld" I am referring to, is the "RealWorld" of that control. And absolutely not any "RealWorld". Therefore you have to join the Disney-world.

That the "RealWorld" of the user-control can change is trivial. Exactly for that, it is a burden to use standard Access form approach.
In the dynamical way: today asked, tomorrow ready (well perhaps the day after tomorrow).

Was you question really a serious question?


Imb.

 

[Pat Hartman]

First a question. Have you ever build over 100 Access-applications and manage these applications at the same time?
Your arguments seem valid for me for a few stand-alone applications.

I've been building Access applications since version 2.1 in the 90's. I'm pretty sure I've logged more than a hundred by now.

It is not an object, it is the complete description how the user wants to "use" that control.

Things like postal code are truly generic as long as the field doesn't need to handle codes for different countries. If the control needs to handle multiple countries, you need to include code for ALL countries in the world but that's because the rules for validating postal code are specific for each country. They are not different for each application or for each company that needs the application. Other fields aren't so common as I pointed out and may have some common validation but could otherwise be different per application or per client.

So are you keeping code in the tables? Show us a table. Show us the code behind a control.

 

[The_Doc_Man]

Was you question really a serious question?

At least partly serious. It has been my experience that when theory collides with reality, it isn't always pretty. In a development environment that has finite capacity, headaches seem inevitable. Therefore, I'm questioning how many times you have had to modify your magnum opus?

 

[Imb]

Thanks for indulging my curiosity. As I thought, your generic form is pre populated with some controls. I was wondering how you decided how much of each control to put on your generic form. For example, I see a few Checkboxes, is that enough for "all" situations?

Hi theDBguy,

All what I have is the result of continuous result of generalisation code, so it is/was a long evolutionary path, with successes but also with failures. Where I say that I have one "The" form, I have actually two: one for continuous records, and one for all the rest.
In the continuous from I think I can handle 20 fields. The maximum I reached one time was I think 18 fields. More fields are not likely, because you can better think of some redesign of the table.
In the form of the rest I can accomodate 20 subforms, that each contain 66 controls. I needed that number one time, and until now that seems enough.

The controls in the Header are partly used as column header for the subform, the rest to hold status information of the form.

The "user-controls" are in the Detail-part. In first instance I had all kind of controltypes, but practice learned that you have always a short of one of the types. And the counting is rather complex.
Then I decided to use only textboxes, that are tuned to their function. The additional advantage is that you can make a mix of all.
So, a Label can also used as textbox, including backcolor, and in the same time react on click as a command button.
For a Checkbox I use now Chr(97) of the Marlett font, with a toggle-function on Click.

The Buttons in the Footer had their function in the past, but will disappear in future. They are still there for backward compatibility.

The absolute number of Checkboxes is on this moment 1320, enough I think.

But there are also escape possibilities. On this moment I use the same subform for all the positions. It is no problem define Super-subform, or a mini-subform instead of the standard subform.


Imb.