命名范围的类别-Excel VBA

Question

I am in the process of continuously updating and improving a financial model built in Excel with VBA macros enabled that is in active use by multiple people. Primarily, these templates are used as budgets for different projects, so there are many created all the time while older budgets are re-visited.

I am the "keeper" of the template while the other users simply use the document. Whenever I need to push out an update to everyone, it creates an issue because they already have created the budget in an older version of the template and to re-create the budget in the new template would take an inordinate amount of time.

I have gotten around this problem on smaller-scale templates by naming ranges and then applying those named ranges to an old version and then using the named ranges to copy into the same named range in the new version of the template. However, this was done with individual lines of code to copy each named range.

Is there a way to aggregate a group of named ranges into a class so that Excel can just loop through all of the items in the class and copy the data rather than me needing to code out each line to perform a copy?

Here is a sample of the code that I am currently running:

Workbooks(WB_Active_Name).Sheets("Office Staff Input").Range("Office_Employee_Names").Value = Workbooks(WB_Secondary_Name).Sheets("Office Staff Input").Range("Office_Employee_Names").Value
    Workbooks(WB_Active_Name).Sheets("Office Staff Input").Range("Office_Employee_Positions").Value = Workbooks(WB_Secondary_Name).Sheets("Office Staff Input").Range("Office_Employee_Positions").Value
    Workbooks(WB_Active_Name).Sheets("Office Staff Input").Range("Office_Employee_Numbers").Value = Workbooks(WB_Secondary_Name).Sheets("Office Staff Input").Range("Office_Employee_Numbers").Value
    Workbooks(WB_Active_Name).Sheets("Office Staff Input").Range("Office_Employee_Bonus_Sharing").Value = Workbooks(WB_Secondary_Name).Sheets("Office Staff Input").Range("Office_Employee_Bonus_Sharing").Value

There are dozen of more lines of code similar to this for each named range. Inside the template, the ranges refer to lists of names of staff, ID numbers, hours worked, etc. and they also span multiple sheets within the workbook with each range of different size.

I am wondering if there is some sort of class that I could place in front of each named range when I define it so that they are treated as a class together and can be looped through. For example:

Office_Employee_Names

becomes

GroupClass.Office_Employee_Names

Then the code could loop through everything in GroupClass

Answer 1

IF an MVC pattern would exist in VBA, then a named range could represent a View object.
I personally have some experience with an MV* pattern where Views also implement events (which are normally delegated to Controller objects).

The benefit of using this approach, is that you will start programming in a much more modular fashion.

I provide an example below:

The structure of an MV* implementation of a simple named range "persons" could have the following class structure:

• cls_view_persons
• cls_model_person

Imagine that cls_view_persons represents a view object, then this would mean that you have to instantiate it from a base sub, which will simply be:

dim view_persons as cls_view_persons 
set cls_view_persons = new cls_view_persons 

1. persons view (example)

The cls_view_persons class will have a property that defines the range of the class. For example:

private pRange as new Range 

You can define the private pRange property in the class constructor.

One of the things that makes Excel buggy, is the fact that you don't know in advance the size of the range, and the fact that mistakes happen, such as a range that was not properly cleared the last time.
This is why it is important to also define the following properties:

• _oRange as Excel.Range
• _sNamed_range as string;
• _lNr_rows as long;
• _iNr_cols as integer;
• _iOffset_x as long;
• _lOffset_y as integer;
• oCollection as Collection (you can also use a dictionary for this)

Note: oCollection is an object that will consist of the different cls_view_persons instances;

and methods:

• Init: class constructor: defining a default range object, or you could pass a range on creation time if you wish to do so;
• get_named_range: returning a range object;
• set_named_range: setting the range object property and creating the named range in the sheet object;
• collection_to_array: converts the collection object into an array;
• clear_range: clearing the range;

• A render method that uses the previous three methods and writes data from the created array to the range in a single statement:

  set pRange = vPersons

Where vPersons is an array, containing the different persons (see later).

• (A "read" method that reads from the range would be useful as well).

  2 person model (example)

A model represents the data logic of your application and is on itself, not necessarily related to one specific view. In this case it is, but a model (or Collection of models) is in principle independent).
A person model could be a class that defines the following properties:

• firstname
• lastname
• address
• country

Either these models are fetched from a database, from an Excel sheet (the latter being the worst scenario, which unfortunately happens the most) or any other source.

Whatever you do, you need to see that you end up with a Collection object that you can feed to the View object.
Once this is done, the View object should manage its own. All interpreting and rendering is delegated to this object from that moment on.
This means:

• Verify the dimensions;
• Clear the previous results;
• Render the range on the screen (ie. setting the new dimensions, creating the named range in the sheet, converting the collection into an array, and writing the array to the screen).

You will see that this approach has many benefits in terms of:

• Maintenance;
• Less bugs;
• Modular (and transferrable) / encapsulated properties / methods;
• Dynamically adaptable;
• You can read from any data source, if you only write an intermediary "translator" module.

Answer 2

I would create a new worksheet in your template that list all these named ranges; read the list from VBA and loop through them.

Answer 3

I often retrieve data from Names by:

Workbook.Names contains all Name Objects, and each Name Object its properties

Dim WBook As Workbook
Dim WName As Name

Set WBook = ActiveWorkbook
For Each WName In WBook.Names
    Debug.Print WName.Name, WName.RefersToLocal
Next WName