Dynamic/reusable forms

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

Hi Mark_,

Yes, I know, but that is not the point.

The point is when you start your 4th, or 5th ..., application that needs a postal database, and moreover the current systematics "must" be extended, then you have quite a lot of copy/paste work.
Better is to have one shared system. When standard forms are involved, it is very difficult, because forms can hardly be shared between the applications.

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.

No interest in Clarion. I want to use Access, with dynamical forms.

Imb.

 

[Imb]

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.

No, the form is already build, only filled on the fly. And that in any way that is handy for the current problem.
I like Access the same way as you do, but if you manage many, many applications, maintenance becomes a problem, because each application is in a far extent independant of the other applications.
The blocking parts are in my opinion the forms.

Imb.

 

[Pat Hartman]

No, the form is already build, only filled on the fly. And that in any way that is handy for the current problem.

No, since you are not using combo boxes or subforms, you are creating arrays of controls at run time OR, maybe you do that initially and then save the customized form rather than building it out at runtime. We can't actually be sure.

Maintenance isn't a problem for me. I have a lot of standardized functionality in my template database. It includes most of the common tools I use. But the guts of the apps don't cross over into other apps. They all stand alone. Once I build an app, I don't go back and update it if I make an enhancement to a common component UNLESS the enhancement would be beneficial to distribute. Then I just import the object and replace the earlier one. New apps get the updated common code. Most of the common code/forms/etc haven't changed for a decade or more. It's not like they're volatile. Once common objects are built and tested, they rarely ever get changed.

 

[Edgar_]

After 100+ posts, the conversation seems to be going in circles, so... like, show a "To Do" app generated by your framework maybe? no idea why forum members think it's impossible to do what you say you did, but you also don't seem to have a clear intent with this thread and it has been alive for one month already.

 

[Mark_]

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.

Template let you specify what data source you had for validation, then you'd pass the fields to fill.
No more of a problem than a DLookup. Pass "PostalCode" and "Field(s) to fill". If more than one value was valid, returned (iirc) a list separated by CRLFs. Normally you'd have a drop down that accepted the results. Been about 30 years since I dealt with that add on. The internal code was very straight forward. You would select, per form, if you wanted it added or not.

 

[Mark_]

Hi Mark_,

Yes, I know, but that is not the point.

The point is when you start your 4th, or 5th ..., application that needs a postal database, and moreover the current systematics "must" be extended, then you have quite a lot of copy/paste work.
Better is to have one shared system. When standard forms are involved, it is very difficult, because forms can hardly be shared between the applications.


No interest in Clarion. I want to use Access, with dynamical forms.

Imb.

If you have the template, you have the template. No copy or paste. Not sure why you would think that. Benefit is per application you only have included what you need. There is no benefit to include address verification for an application that does not track addresses.

 

[Imb]

no idea why forum members think it's impossible to do what you say you did,

Let me try to describe in short how the dynamical forms work. Some parts I will skip on the moment, because it will disturb all the readers too much, I suppose.

I have a table "A_Veld_tbl" with all the fields from all tables in the application. See before.
I have also a dynamical form with only a number of hidden controls. They are already prepared that the most important events of the control (Enter, Click, Exit, Keydown, Mousedown, ...) have already a procedure defined in a linked General database, resp. On_ctl_Enter, On_ctl_Click, On_ctl_Exit etc. (but the name itself is not important.)

As an example I will define an continuous form.
From A_Veld_tbl I select the records with Item = "Persoon" and Overzicht = TRUE.
Using this recordset I make the systematically named control visible, give them the needed width (Breedte), and make the visible. Also each control is tagged with the corresponding "A_Veld_id", a kind of binding to the originating field.
The RecordSource of the form is set, mostly using a predefined (but automatically generated) join-construction, and completed with a WHERE-clause and ORDER-clause, also defined in A_veld_tbl.

In my applications Overzicht-forms are not editable. But for this example suppose they are, and you want to edit a certain control.
As soon as you enter a control, it gets the focus, but also its current value is stored in a global "Veldwaarde", and the corresponding A_veld_rec is opened using the tagged A_veld_id. Now all is known about the field!!!
During typing a new value all kind of corrections can already be done.

When finished, the On_ctl_Exit procedure is runned.
First line in this Sub is to exit when the control's value = Veldwaarde: nothing has changed.
If the control is changed, the new value is verified against the "BeforeUpdate conditions". If these are violated, the Cancel = TRUE, and the Sub is exited.
With no violations the new value is stored, in the appropriate table in the appropriate field (available in A_veld_rec), and "AfterUpdate actions" are carried out.

This in a bird's-eye view. Applicable for any Item in any application, using the definition tables A_Veld_tbl and A_befores_tbl.
Result is a kind of Dataview form, with all flexibility of the Dataview form, but also with all the constraints necessary to build a robust database system.

I can describe many more aspect of the use of dynamical forms.


Imb.

 

[Edgar_]

Let's suppose you want to build a contacts list.

I suppose the first step for you is to open a blank file with the framework prepared, right? The framework items in your file has some code modules, tables for the metadata and forms to define the fields. All is well here, right?

The second step should be to build a table right? If so, let's say this "contacts" table has these fields: Id, FirstName, LastName, Phone

Then, using your framework, you open the form where you "connect" or "bind" the elements to your framework, is that right? If so, after opening the form, you would choose which table you want to bind to your framework. In that case, you select "contacts" and then the fields show up in a continous form. Said continuous form lets you specify the role of each field in the table using your framework. Is that right?

Once each field has been set up, you save this and it's added to a menu or something? Then you do the same for other tables. Finally, it's just a matter of opening the menu form and you will be able to work with the system. Is that right or not at all?

 

[Imb]

Let's suppose you want to build a contacts list.

I suppose the first step for you is to open a blank file with the framework prepared, right? The framework items in your file has some code modules, tables for the metadata and forms to define the fields. All is well here, right?

The second step should be to build a table right? If so, let's say this "contacts" table has these fields: Id, FirstName, LastName, Phone

Then, using your framework, you open the form where you "connect" or "bind" the elements to your framework, is that right? If so, after opening the form, you would choose which table you want to bind to your framework. In that case, you select "contacts" and then the fields show up in a continous form. Said continuous form lets you specify the role of each field in the table using your framework. Is that right?

Once each field has been set up, you save this and it's added to a menu or something? Then you do the same for other tables. Finally, it's just a matter of opening the menu form and you will be able to work with the system. Is that right or not at all?

Hi Edgar_,

In general you are heading in the right direction, in detail it is a little different.
It is now late here, and it will take me too long to explain my way of working, but tomorrow I will come back.


Imb.

 

[Imb]

Let's suppose you want to build a contacts list.

I suppose the first step for you is to open a blank file with the framework prepared, right? The framework items in your file has some code modules, tables for the metadata and forms to define the fields. All is well here, right?

The second step should be to build a table right? If so, let's say this "contacts" table has these fields: Id, FirstName, LastName, Phone

Then, using your framework, you open the form where you "connect" or "bind" the elements to your framework, is that right? If so, after opening the form, you would choose which table you want to bind to your framework. In that case, you select "contacts" and then the fields show up in a continous form. Said continuous form lets you specify the role of each field in the table using your framework. Is that right?

Once each field has been set up, you save this and it's added to a menu or something? Then you do the same for other tables. Finally, it's just a matter of opening the menu form and you will be able to work with the system. Is that right or not at all?

Hi Edgar_,

It wouldn't suprise you that I have a "Database of Databases", which contains all my applications. It is a.o. used for contact information towards the user(s).
But this application also has tools to analyze all applications. Since application specific information is only stored in definition tables and general modules, all can be viewed or manipulated from this application. No FMS- or other addins necessary.

When I add a new record to this database, a new application is started by copying an "empty" database with the new name, including the linked General database. It is already fully functional with almost all of its future functionality. But without data.

Within the new database I can define a new Item: Contact. I like the singular, because its is less complex then the plural in my mother language. Just by defining the Item name, a table is generated in the BE, named Contact_tbl, including a PK-field Contact_id, and a universal boolean field "Selectie". This definition is also stored in a meta-datatable "A_Data_tbl" in order to synchronize the the BE of the production database, with all changes regarding the data done in the BE of the development database.

When the table Contact_tbl is defined, you can add the fields FirstName, LastName, Phone. In fact this is done by adding a record to A_Veld_tbl for each field, with the definitions for that field. The new fields are also added to the A_Data_tbl.

At this point your application is ready, with complete functionality.
Only missing some data ...

A 20-tables database can be defined in no time.

Imb.

 

[Edgar_]

Neat, I can understand despite the language differences, so thank you for clarifying.

That is a nice framework indeed, and I can see how it would benefit you in creating new applications. There must be quite a lot of work behind so kudos for that. There really is no problem in you encapsulating the default capabilities of MS Access if it makes you more productive, although it is definitely harder to bring-in new devs into it because things have been named in your mother language.

Anyway, what do all those extra controls do in the end form?

 

[Imb]

Anyway, what do all those extra controls do in the end form?

Hi Edgar_,
Yes, about the English/Dutch mix, it needs still some upgrading, but as far as I can see that is not a big problem.

The end form is perhaps a little misleading.
The left part shows the "menu" with Items, the only one being Contacts.
In the right part you would see the contents of the "whole" table.

But that was not so interesting, because the table has no records.
But if there were records, you could select the records on any field, on almost any condition.

The selected field is FirstName, default "beginning", but you can choose any condition from the column "Selecteer conditie".
The choices are:
beginnend = starting
gelijk = equal
bevat = contains
eindigend = ending
joker = wildcard
AND-woorden = two or more strings must be found
OR-woorden = at least one of two or more stringd must be found
tussen = between, in alfabetic order
heel_woord = string as a separated word
sound = primitive function on mostly consonants
Null
Not Null

This "Selection-form" is also used to select a recordset that is used as a substitute for comboboxes.


In your database there are only fields with Veldtype = "T" (String). You can choose any Fieldtype that is valid in Access.
But more! You can work with incomplete dates, or time-units (15 min, 5 min units) or more important: FK-fields.
These FK-fields connect al tables together, and are the basis for all Integrity control from the FE. That is, never need to go to the BE to control these things.
They also make that you can "walk" through the whole database, in one direction or the other, which makes the mainform/subform construction redundant, including all comboboxes.


Imb.