Considering how tiny the applications are and how simple the screen is - heck I'd just put it in one application if it was me. There might not be any design advantage to it since there isn't any code that can be reused - but hey my thinking is that if it eliminates 1 chance in a million that you won't have a 'user issue' ...then heck go for it.

>I'd like to have people help out in figuring out a programming issue that a co-worker and I are having a strong disagreement on and we cannot proceed with our coding effort until it is resolved.
>
>We are completely stuck and we both acknowledge that fact. I am offering a coin toss, but she will not allow that. Therefore, I am requesting the experts of Universal Thread to help us out.
>
>I’ll try to be honest in my description of the problem.
>
>Ok, here's the scenario:
>
>We have a need for either one or two small VFP9 applications that take less than one minute to run.
>
>Our Production team (“the button pushers”) run a morning and an afternoon production schedule where they bring up one application at a time and typically press a “RUN” button and wait until a status label says “Done with 0 errors”. Pretty simple stuff.
>
>At this point in time the afternoon production schedule has maybe 5 to 20 of these little applications to run.
>
>My co-worker strongly believes that adding two (2) and not just one (1) applications puts us at risk where the button pushers might miss running an application and she says:
>
>“because the processes are so similar and because it is one less step for production, we do not want to complicate an already complex afternoon production process/schedule for staff that already miss steps”
>
>I estimate that the button pushers get it (the entire production schedule) right about 97% of the time or better. Most of the time they are 100%.
>
>Now, let me discuss the code side:
>
>Basically, we already wrote one of the applications the other day. It is complete and ready to go.
>
>The application has one form, one report, two tables (runs and error_log). There are a total of fifteen (15) methods including load, init, etc. in the main form. There are ten (10) custom methods other than load, init, etc.
>
>My coworker wants to re-open the finished app (the main form) and add two checkboxes for each of the two (2) operating modes and add eight (8) methods that will pretty much behave similarly to the existing methods and will even be called similar names, but the code will be different enough that there will be no reusability. As far as I can tell there will be three method that can be reused, the shorter, simpler methods.
>I’d rather create a new small application for the new operating mode rather than retrofit the single application to operate in two (2) modes. I believe that under the circumstances two applications is cleaner and follows better coding standards and design guidelines. I see the similarities between the 2 applications, but, again, I don’t see much code reuse at all to complicate the form with 8 additional methods and code that forks to one operating mode or the other or both.
>
>And, no, I see no point in subclassing the form since there is very little code reuse other than the method names (getDataFromSql, updateSqlData, etc.)
>
>So, I’m asking for opinions on the two options here. Either one large more complicated application or two smaller more straightforward applications that virtually do the same thing.
>
>Thanks