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.