Component Design (1 Viewer)

We have migrated our design efforts to be completely modular. I use the word "Component" instead of "Modular" because modules already exist and to differentiate it from that, we refer to the process as Component Design.

So I thought we could have a discussion of the complexities of component design, and some of the processes we have adopted to deal with them.

The advantages are obvious, the ability to reuse components is paramount to developing increases in productivity.

Have any of you made significant progress in this, and what do you see as the biggest obstacles?

From context, I infer that you are referring to somehow re-using Access modules in multiple applications. If that is correct, I have had some success.

The issue often is recognizing when you can get away with re-using code and when you can't. Here are some thoughts in no particular order.

If you are going to design a general module to do something commonly done, don't forget to define required data elements in the specific module's declaration area, even if you want the values to be public within the application.

If you are going to reference something outside of your general module, always pass in anything that might even remotely be considered foreign to your module. For example, always pass in a form name or an Access.Form object (this is a trivial case). Always pass in user identification data rather than relying on being able to get it globally.

In other words, avoid programming side-effects to the greatest extent possible.

Another thing I've found is useful in this context is to "think primitive." By that, I mean more specifically to set very modest goals for individual modules. Think along the lines of implementing "primitives" - say, for example a set of actions such as

• Open a workbook given a file spec and an Excel Apps object
• Open a worksheet and select it given an opened workbook with sheets
• Fill in a single cell (with text and attributes) given worksheet object, row, column, text, color choices
• Determine the attributes of a cell given worksheet object, row, and column
• Determine the number of non-blank rows given worksheet object and column (or maybe the column with the greatest number of rows)
• Determine the number of non-blank columns given worksheet object and row (or manybe the row with greatest number of columns)
• Create a new worksheet (and select it) given a workbook object
• Close the workbook (and update it) given a workbook object

These are primitive operations selected here for the sake of discussion. Sure, for this case it isn't that hard to do these directly in VBA code. But the idea being illustrated is that you should think about elementary functions, not huge hulking complex routines. The more complex your routine, the more likely you are to have to "bang on it to make it fit" (square peg, round hole concept).

I've made this work for Excel operations, Word operations, Outlook operations, Windows operations, Access Control Appearance operations (formatting my controls in consistent and meaningful colors), security arbitration functions ... each in its own module that has at least some level of generality.

Does this help?

That is some great ideas.
For my re-usable code I keep a table with an autocounter. The table describes the name, has the function call (that can be copied, pasted later). It incluedes a short detail description.
Another feature I use is the Message. For common code, the error or other important messages are centralized. Just look up the number.

Using the Optional parameters also comes in handy.
All of mine are Functions. Even if a return value is not needed, return a pass/fail.
For the rule engine type, everyting returns a -1 (pass) or a number (looked up in a table) for the reason it did not pass.

The curse of Code Resuse is when one function is changed. It requires a Quality Assurance test. Everytime that is overlooked because it shouldn't make any difference, the Laws Of Murphy come into effect. So, for the younger crowd, with the great power of re-uesable code comes great responsibility.

Hey Guys,

Thanks for taking an interest.

At this point I'd like to expand the definition of component to include standardized groups of database and user interface objects. Over the years, most everyone has made new parts that fit together based on copying a form, or a query, or some other objects.

But, what if you designed a system from scratch, that was completely integrated components. It sounds simple, but it is rather complex in nature.

First, you have to decide on a naming scheme that allows the system to be mix and match without duplication across dozens of components and hundreds or thousands of objects.

Next you have to keep track of dozens of public variables and functions

And, (for now) last; each piece must work as a standalone and as part of any combination of components. To to that end, we made a variable and function server, which all component share by setting a reference to the file. All components are front ends linked to development, and production, back ends.

In the variables server we also have a database of code snippets, and forms to create and manage public variables, and object naming. In the developing version of the different components, strict adherence to version management is essential.

We install a group of forms and queries in each developing component that give us the value of public variable.

And the last part is that we have a project management database that prioritizes, sorts and delegates development.

I have all these tools but they are very basic, in that very little documentation or user interface has been utilized. However, they can be made open source if y'all want to try them out. I would ask that improved version were posted back to the forum

Another thing I've tried before with some success is a "prototype" form for which all of the form-specific event modules were pre-programmed but the control-specific events were less fully populated. That is, FORM OPEN, FORM LOAD, FORM CURRENT, FORM UPDATE, FORM CLOSE, FORM UNLOAD are populated fully.

My forms always have command buttons for HELP, FILE TROUBLE REPORT, COMMIT, CANCEL, and CLOSE. Some also have CREATE and REMOVE. For the command buttons, the skeletons of the event code are complete but the details that depend on the contents are left for another time. There is usually a SetButtons routine to make the command buttons line up and it also turns off some buttons (and makes them invisible and not active) when they should not be shown. (Like when there is nothing to commit or cancel, or when the form is dirty and I don't want it closing prematurely.)

Some of my forms have common fields like the "description of control currently in focus" (Which I call the "Hints" box) and the "Logged in User" (the USERIS box) and the user's role (the ROLEIS box). All the forms will use that information so all the forms have it from the prototypes. There is also a "Form's Public Name" (the "FormLongName" box, which is a label) and a couple of pre-fabricated image areas for the corporate logo.

This does a couple of things for me. First, it assures a consistent look-and-feel. Second, it takes maybe 30%-50% off development time because a lot of the tedious stuff is already done. Depending on how much is on the form, this is big help. Even for complex forms, having 30% of that code done already gives me an edge.