Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I appreciated knox's and david's answers. My answer will be somewhere between theirs: just make <strong><em>forms that do not need to be debugged</em></strong>!</p> <p>I think that forms should be exclusively used as what they are basically, meaning graphic interface <strong><em>only</em></strong>, meaning here that they do not have to be debugged! The debugging job is then limited to your VBA modules and objects, which is a lot easier to handle. </p> <p>There is of course a natural tendency to add VBA code to forms and/or controls, specially when Access offers you these great "after Update" and "on change" events, but I definitely advise you <strong>not</strong> to put any form or control specific code in the form's module. This makes further maintenance and upgrade very costy, where your code is split between VBA modules and forms/controls modules.</p> <p>This does not mean you cannot use anymore this <code>AfterUpdate</code> event! Just put standard code in the event, like this:</p> <pre><code>Private Sub myControl_AfterUpdate() CTLAfterUpdate myControl On Error Resume Next Eval ("CTLAfterUpdate_MyForm()") On Error GoTo 0 End sub </code></pre> <p>Where:</p> <ul> <li><p><code>CTLAfterUpdate</code> is a standard procedure run each time a control is updated in a form</p></li> <li><p><code>CTLAfterUpdateMyForm</code> is a specific procedure run each time a control is updated on MyForm</p></li> </ul> <p>I have then 2 modules. The first one is </p> <ul> <li><code>utilityFormEvents</code><br> where I will have my CTLAfterUpdate generic event</li> </ul> <p>The second one is </p> <ul> <li><code>MyAppFormEvents</code><br> containing the specific code of all specific forms of the MyApp application and including the CTLAfterUpdateMyForm procedure. Of course, CTLAfterUpdateMyForm might not exist if there are no specific code to run. This is why we turn the "On error" to "resume next" ...</li> </ul> <p>Choosing such a generic solution means a lot. It means you are reaching a high level of code normalization (meaning painless maintenance of code). And when you say that you do not have any form-specific code, it also means that form modules are fully standardized, and their production can be <strong><em>automated</em></strong>: just say which events you want to manage at the form/control level, and define your generic/specific procedures terminology.<br> Write your automation code, once for all.<br> It takes a few days of work but it give exciting results. I have been using this solution for the last 2 years and it is clearly the right one: my forms are fully and automatically created from scratch with a "Forms Table", linked to a "Controls Table".<br> I can then spend my time working on the specific procedures of the form, if any.</p> <p>Code normalization, even with MS Access, is a long process. But it is really worth the pain!</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload