[AccessD] Select case is too cumbersome

On 6/16/05, Hale, Jim <Jim.Hale at fleetpride.com> wrote:
> I have a form which lists different Excel workbooks I can populate. When I
> make a selection from the form I read the path to the appropriate excel
> template  and the select case number from a table. I pass these to a
> function  "Public Function Load_Financials(intCaseno As Integer, strpathname
> As String)" for processing. The function opens the appropriate Excel
> template and, based upon the select case number, populates the template from
> various recordsets and formats the workbook as appropriate. All of this
> works fine. My problem is that I am up to case 40 in my select statement.
> Many of the cases are quite lengthy so Load_Financials is getting out of
> hand. 5 cases was no big deal, 40 and 500 lines of code is a bit much.
> Surely there is a more elegant way to arrange this. For example, I read "Two
> functions you don't use enough" in this month's Smart Access which suggested
> each case can be placed in its own function and the EVAL function can be
> used to execute them. How do ya'll handle this issue?
> 
> Jim Hale
> 
If you're just speaking from an Access perspective, I'd haev one
function with just the SELECT / CASE statement, then for each case,
call a seperate function for the differences.

If some of your cases have the same code for chunks, you could group
them in one function and call the function in the Case statement.

For example, creating an excel file, formating a header, formatting
the data, then saving, you could seperate it into 4 functions: Create
file (before the case), Format Header and Format Data within the case,
then Save File / Write Data at the end.

This way you would have a set of stable functions and can save
yourself from redundant work / large files.

-- 
Josh McFarlane
"Peace cannot be kept by force. It can only be achieved by understanding."
-Albert Einstein