Code Generators (1 Viewer)

juanbalv

New member
Local time
Today, 12:49
Joined
Jan 16, 2019
Messages
6
I know I am lazy. I did a bit of work in the dBase III plus days, worked with Clipper before it was destroyed by Computer Associates. I guess I am dating my self. The last 14 years before my retirement in 2014 I worked as a fairly powerful power user with various flavors of MS Access.

I have just been challenged by an old friend to develop an Workforce Development Application for the non-profit world, and I thought, given a relational database model where all tables, relationships, queries, and reports are defined, is there such thing as a code/application generator out there to help with the initial grunt work? PLEASE, HELP.
 

June7

AWF VIP
Local time
Today, 11:49
Joined
Mar 9, 2014
Messages
5,423
Have to say no. Access is a development tool that does help with the 'grunt' work. It has wizards and designers that can do a lot for you but you still have to tell it what you want. I seldom use the wizards because they do things I don't like.

Define "Workforce Development Application". Exactly what data will this db contain?
 
Last edited:

theDBguy

I’m here to help
Staff member
Local time
Today, 12:49
Joined
Oct 29, 2018
Messages
21,358
You could try looking for templates where the initial grunt work are already done.
 

juanbalv

New member
Local time
Today, 12:49
Joined
Jan 16, 2019
Messages
6
Have to say no. Access is a development tool that does help with the 'grunt' work. It has wizards and designers that can do a lot for you but you still have to tell it what you want. I seldom use the wizards because they do things I don't like.

Define "Workforce Development Application". Exactly what data will this db contain?
The db will track program participants, stake holders, such as prospective employers, CBO's providing a referral stream to the program, it will also track projects where the prospective employees are or will be placed, inclusive of hours, worked, pay rates, and a variety of reporting mechanisms, through a healthy application of canned and on the fly queries. Nirvana, ha?
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 14:49
Joined
Feb 28, 2001
Messages
27,001
June7 and I think similarly in many ways but I differ with her on one point. The wizards are GREAT ways to quickly build a scaffold on which you can go back and customize things. Yes, they are as dumb as a box of rusty garden tools - but they are effective when building certain types of command buttons, combo boxes, list boxes, and special events.

One method I used to make things go faster was that in a particularly large app, I realized that I would have MANY forms that were going to have to do similar things. So I built a couple of "faceless" template forms that had a bunch of command buttons built in ahead of time.

For instance, my table maintenance forms all would have command buttons to SAVE (any edits), UNDO (any edits), CREATE (new records), DELETE (old records), CLOSE, and FILE TR (pop up a trouble-report form). They would all have the same logo in the upper left corner, they would all have titles in the top center area, and they would all show the user's login name and role (which I knew I would look up from a Users table). They would all have the same look-and-feel so they all had the same background and color scheme. There were other things behind the scenes, like BeforeUpdate events so that you could not accidentally update a record by navigating, you had to SAVE. They had audit logging built in to show what form, what record, and what user were involved in anything permanent like SAVE or DELETE. They had common error trapping support routines so when you trapped an error, you made one subroutine call to do the pop-up box (if you wanted it) and the error logging. When I was finished, perhaps 50% to 60% of what I was doing on that form behind the scenes was already handled even before I filled in any .Recordsource or controls. Then each time I needed to do that same sort of thing, I just copied the template and customized it for its final purpose. In my case, turned out I had at least two dozen of the maintenance forms for over two dozen tables.

The problem with code generators in general, and perhaps the reason that June7 is down on the wizards (which are, after all, code generators) is that "automatic systems" have no imagination, no guarantees of efficiency, and at best a highly limited style. It is why so many data-driven design systems are losing ground. The key to such systems is the code library from which they can draw, and I learned this rule a long time ago: 'One size fits all' rarely fits anyone.

I worked for a company (a long time ago now) that tried a system that automatically knew what to do with your data as soon as we designed the database. And it was right enough times that we were ahead of the power curve. But we ALWAYS had to customize. We were in the oil and gas industry and were doing leak detection as a feature on one of our pipeline control systems. We had a GREAT algorithm that complied with EPA standards and treatments. It understood viscosity, used virial equations to account for gas dynamics at high pressure, had lots of features. So we included it with our systems. Five years after we introduced it, we had 24 customers and 25 different leak-detection algorithms - ours and each of theirs.

Therefore, I understand why some folks are down on wizards. But when your goal is a RAPID (stress rapid) application development, the Access wizards can get you up and running fast. Then you refine the product by stepping in and tweaking or (as needed) replacing the code that was built for you.
 

juanbalv

New member
Local time
Today, 12:49
Joined
Jan 16, 2019
Messages
6
June7 and I think similarly in many ways but I differ with her on one point. The wizards are GREAT ways to quickly build a scaffold on which you can go back and customize things. Yes, they are as dumb as a box of rusty garden tools - but they are effective when building certain types of command buttons, combo boxes, list boxes, and special events.

One method I used to make things go faster was that in a particularly large app, I realized that I would have MANY forms that were going to have to do similar things. So I built a couple of "faceless" template forms that had a bunch of command buttons built in ahead of time.

For instance, my table maintenance forms all would have command buttons to SAVE (any edits), UNDO (any edits), CREATE (new records), DELETE (old records), CLOSE, and FILE TR (pop up a trouble-report form). They would all have the same logo in the upper left corner, they would all have titles in the top center area, and they would all show the user's login name and role (which I knew I would look up from a Users table). They would all have the same look-and-feel so they all had the same background and color scheme. There were other things behind the scenes, like BeforeUpdate events so that you could not accidentally update a record by navigating, you had to SAVE. They had audit logging built in to show what form, what record, and what user were involved in anything permanent like SAVE or DELETE. They had common error trapping support routines so when you trapped an error, you made one subroutine call to do the pop-up box (if you wanted it) and the error logging. When I was finished, perhaps 50% to 60% of what I was doing on that form behind the scenes was already handled even before I filled in any .Recordsource or controls. Then each time I needed to do that same sort of thing, I just copied the template and customized it for its final purpose. In my case, turned out I had at least two dozen of the maintenance forms for over two dozen tables.

The problem with code generators in general, and perhaps the reason that June7 is down on the wizards (which are, after all, code generators) is that "automatic systems" have no imagination, no guarantees of efficiency, and at best a highly limited style. It is why so many data-driven design systems are losing ground. The key to such systems is the code library from which they can draw, and I learned this rule a long time ago: 'One size fits all' rarely fits anyone.

I worked for a company (a long time ago now) that tried a system that automatically knew what to do with your data as soon as we designed the database. And it was right enough times that we were ahead of the power curve. But we ALWAYS had to customize. We were in the oil and gas industry and were doing leak detection as a feature on one of our pipeline control systems. We had a GREAT algorithm that complied with EPA standards and treatments. It understood viscosity, used virial equations to account for gas dynamics at high pressure, had lots of features. So we included it with our systems. Five years after we introduced it, we had 24 customers and 25 different leak-detection algorithms - ours and each of theirs.

Therefore, I understand why some folks are down on wizards. But when your goal is a RAPID (stress rapid) application development, the Access wizards can get you up and running fast. Then you refine the product by stepping in and tweaking or (as needed) replacing the code that was built for you.

Thank you Sir. I really do appreciate the effort you provide in your answer. It has been 4 years since I retired and haven't really kept my skills, coding wise, or otherwise, vis-a-vis Access development. I will take an in depth look at the wizards and get back for advise as I go.
 

CJ_London

Super Moderator
Staff member
Local time
Today, 19:49
Joined
Feb 19, 2013
Messages
16,553
one comment I would make is that if you get the table/relationships/indexing right first, form and report generation becomes much easier
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 14:49
Joined
Feb 28, 2001
Messages
27,001
CJ is flat-out right. The wizards can "see" the relationships and use them constructively.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 15:49
Joined
Feb 19, 2002
Messages
42,973
You can't get around the grunt work of defining the schema. There is nothing magical about that. You and the user need to decide what data you need to track and come up with some concept of how data should be entered and reported on.

Once the tables are built and RI is enforced, build queries to select the rows and columns needed and use those queries as the RecordSources for forms and reports. Both the form and report wizards will lay out an initial form or report which you can then make pretty. I almost always use these two wizards even though in the end I almost always have to move everything but it is a start and in some simple forms/reports, the wizard will do most of the layout.

Use Themes to control how things look. Try not to set font/color and other visual attributes on a control by control basis. That allows you to simply change the theme to change the color scheme or font. Just be careful since themes are not interchangeable due to their differing font sizes. If you layout the form using a theme with a 12 point font and switch to a 10 point font based theme, everything will overlap unless you've left a lot of space between controls so there is still a lot of room for improvement in the way themes work.
 

Users who are viewing this thread

Top Bottom