Copy from http://www.excelforum.com/showthread...11#post4551509 https://www.excelforum.com/developme...ml#post4551509
_1 ) Referring to Range Objects in VBA
I guess to some extent, I may be questioning / commenting on two basic statements or ideas
_(i) ... “...the most basic way of referring to Excel’s VBA Range object: the Range ( or Cells ) Property..”...
and
_(ii) whether there may be an additional Range Object ( The Application Range Object ) , that is to say , additional to the
..”... Range Object is “ .. (always ) .. “ contained within the Worksheet Object...”...
The latter, _(ii) , is possibly dubious, and possibly I could alternatively be suggesting that we have a sort of Application Range(“ “) Method ( or Application Range(“ “) Property, which is an alternative _c) to _..
_a) Cells Property
_b) Range Property
_.. , and which can be used to reference a Range
_1a ) _1b) Referring to Range Object contained within a Worksheet Object
_1c ) Referring to a ( Application ? ) Range Object
The documentation is not perfectly clear on this, at least that is the opinion of much more VBA experienced people than me. So the following is partly my interpretation.( Especially _1c) ).
I would suggest we can get at a Range Object in three basic ways. I deliberately list things a bit in a jumbled order, as things in the “imaginary” world are often in a seemingly incorrect order.
_1c) Directly through some specific reference.
( http://excelmatters.com/referring-to...comment-197138 )
_1a) indirectly using the Cells Property ( Method ) already discussed. http://www.excelforum.com/showthread...84#post4551080 http://www.excelforum.com/showthread...84#post4551484
_1b) indirectly using a similar Property to that in _1a), which unfortunately someone in their wisdom decided to call the Range Property. This Range Property is a “way” or “Method like” thing and should not be confused with the final big “thing” of the Range Object.
_1a) 1b) The general typical Ideas given for referring to Range Objects in VBA.
Let’s say, I have defined Rng as a Range Object. Then this type of code ( used within the Excel Application in VBA code ): _..
_1a)(i) Rng=Worksheets(1).Cells(1, 1)
or
_1a)(i) Rng=Worksheets.Item(1).Cells(1, 1)
_.. is using the Cells Property of a Worksheet to return the Range Object of the first cell in the first Worksheet ( Index / Item Number 1 counting Worksheet Tabs from the left ).
The same again using a string name ( assuming the first Worksheets has the default English Excel name of “Sheet1” )
_1a)(i) Rng=Worksheets(“Sheet1”).Cells(1, 1)
or
_1a)(i) Rng=Worksheets.Item(“Sheet1”).Cells(1, 1)
Similarly the Range Property of the worksheet can be used
_1a)(ii) Rng=Worksheets(1).Range(“A1”)
or
_1a)(ii) Rng=Worksheets(“Sheet1”).Range(“A1”)
etc.. etc....
My experiments suggest the following is also acceptable for the same, and I am not sure if VBA may actually change _1a(ii) “internally” as it were, to this type of form
_1a)(iii) Rng=Worksheets(1).Range("='[MyFile.xlsm]Sheet1'!A1")
This last :1a)(iii) would still be using the Range Property of the worksheet. I think before and up to this point we are clearly using the Cells or Range Properties of a Worksheet. This last suggestion, _1a)(iii) , I am, in fact not too sure about and in end effect a Range Object must be returned, so this could be how VBA finally sees the final returned Range Object:-
_1b)(i) Rng=Application.Range("='[MyFile.xlsm]Sheet1'!A1")
This last one, I think, is a Range Object, but I am not too sure? We could have used this initially and hence , I think, possibly would have a more basic way of cell referencing with _1b)(i), that is to say explicitly referring to the Application Range. So finally we have _1c) Rng=Application.Range("='[MyFile.xlsm]Sheet1'!A1") ( A suggestion / proposal from me )
_._____________________________
A few further related concepts
Unqualified Range reference,
One sees most typically a shortened version, an “unqualified” Range reference, of this type of form
Rng=Range(“A1”)
This leads to uncertainties.
_A) Used within a Normal code module. The last code line above will default ( that is to say what VBA “sees” ) to this sort of form
_1b)(ii) Rng=Application.Range("='[" & ActiveWorkbook.Name & "]" & ActiveSheet.Name & "'!A1")
which is again, I think, a Range reference, possibly to be regarded as referencing explicitly or directly by a Range Object? So I think we are referring Explicitly through a Range Object.
We are defaulting here, in the case of the code line in a Normal Code module, to the Application Range and not to the Active Worksheets as often said.
It is possible that my idea of an Explicit reference through an Application Range Object could be called an Application Range Property, So I am touching on dodgy uncertain ground here.
Application Range Object *#*#*
http://www.mrexcel.com/forum/excel-q...ml#post4357003
http://excelmatters.com/referring-to...comment-197138
_B) Use of an “unqualified” Range reference for the instance of a Class Worksheets, that is to say put in, for example, the Worksheet code module of Worksheets(2), will default ( that is to say what VBA “sees” ) to this sort of form
_1a)(iii) Rng= Worksheets(2).Range("='[" & ActiveWorkbook.Name & "]" & Worksheets(2).Name & "'!A1")
Which I think is referring through a Range Property.
Range and Cells() ( and Item ) Properties of Ranges ( Range Range Property , Range Item Property ) and Range Cells Property )
We have been talking so far about the Range and Cells() Properties of Worksheets as well as my suggestion of an Application Range ( which we are leaving it uncertain currently as to whether it is an Application Range Object or Application Range Property *#*#* )
In any case we have finally in all cases a Range Object. Regardless of where this is, we have a further (a)(ii)) Range(“ “) and (a)(i)) Cells() Property!!!!!, of a form such as
Range(“A2”) and Cells(2, 1) , or pseudo like
Range(strAddress) and Cells(row_coordinate, column_coordinate)
Specifically here for the Range( ) case, we are limited to an Address string and not a full reference.
The Range and Cells() Properties of a worksheet we have seen extend from ( are referenced to ) the Top left of a Worksheet. Similarly, the Range and Cells() Properties of a Range Object extend from (are referenced to ) the Top left of the range Object. _...
_... For example:
_1c) Rng=Application.Range("=[Workbook]Worksheets(1)!A1").Range(strAddress)
Is applying the a Range Property to the Range Object from _1b)(i)
You can keep going infinitely with rng.Range.Range.Range.Range. Each Range Property returning a new modified Range Object to which the next Range property is applied.
For the case of a Range Object Range Property, negative numbers and negative column letters are not from the syntax allowed.
However for the case of the Range Object Cells() Property, negative co ordinates are permitted.. Note here however two things here:
Firstly, the Range Object will need to have its top left far enough away from the Worksheet Top left origin such that the negative co ordinate applied Cells() Property does not go “further back to the left” or “further back up” than the Spreadsheet boundaries; and secondly, zeros in such as this Property reference, Cells( 0, 0 ) , is also from the syntax valid. So For example, _..
Range("A2:C5").Cells(0, 1)
_.. will return finally the Range Object of the ( cell ) “box” at Address A1, ... ( We apply the Cells() Property to the top left cell of the range Object which is A2. O gives 1 row back up from row 2, and 1 gives the same column as column A )
( ......The Item Property: Many things in VBA can be referenced through a consecutive Item Number, or Index, like 1, 2, 3 ... etc. The order is determined in various ways for the different things. The typical syntax is then Item(Whole_Number) and is usually read only.
For the case of a Range Object, this number relates to each ( cell ) “box” in the Range Object. This ordering follows the typical Excel Spreadsheet ( cells ) “boxes” order convention of numbered from left to right and from top to bottom. We may use this to reference (cells) “boxes” outside the Range Object that lie within the Worksheet boundaries. These "Overshoot" Items follow further the row then column convention , effectively "duplicating down" the Worksheet, that is to say repeating the original Range Object vertically down the Worksheet )..
It is a further confusing aspect of the Range Object that for the Range Item Property we may also use two arguments in the ( ) bracket representing the row, and column. If this option is chosen then we can use Numbers or , for the columns , also the letter (wrapped in quotations). In the two argument case we extend beyond the original Range Object from the top left in the Original Range Object in the usual row, column way, ( we do not proceed in a duplicate type way in Ranges Objects stacked down the Worksheet ) .
!!!!!To complete the confusion_... there may be no Cells Property see next post......).
_..................................
What is all this Post about. ?
Two things really
_( One) 1a) 1b) ) A review of the more common ideas of Range Objects and Range and Cells() Properties, with a mind to going on to make a suggestion , or at least discussion on a , a possible Explicit-er Application Range Object ( or Application Range Property or even Application Range Method )_.. that is to say _1c) _..
_.. _( Two) 1c) ) The end result of all the above, is that I have got recently into always using variations of this type of way to reference a Range Object.
Code:
Sub strRefAppRngObj() ' http://www.excelforum.com/showthread.php?t=1154829&page=11&p=4551509&highlight=#post4551509
' 1c) Application Range Object
Dim strRef As String ' Prepares "Pointer" to a "Blue Print" (or Form, Questionnaire not yet filled in, a template etc.)"Pigeon Hole" in Memory, sufficient in construction to house a piece of Paper with code text giving the relevant information for the particular Variable Type. VBA is sent to it when it passes it. In a Routine it may be given a particular “Value”, or (“Values” for Objects). There instructions say then how to do that and handle(store) that(those). At Dim the created Paper is like a Blue Print that has some empty spaces not yet filled in. String is a a bit tricky. The Blue Print code line Paper in the Pigeon Hole will allow to note the string Length and an Initial start memory Location. This Location well have to change frequently as strings of different length are assigned. Instructiions will tell how to do this. Theoretically a specilal value vbNullString is set to aid in quick checks.. But...http://www.mrexcel.com/forum/excel-q...html#post44 '
Let strRef = "='[" & ThisWorkbook.Name & "]" & Worksheets.Item(1).Name & "'!A1:C3"
Dim Rng As Range ' EP Dim: For the Variable type declared, there should be some Blue Print or master Instruction list. If not The code will error at the start as it need to examine and therefore prepare for usage of the variable in the code run. The variable itself will go to some “Pigeon hole” that has a copy of the instructions or in some way has information on how to use the original instructions such that it can distinguish between different variables of the same type. When the code meets the variable it will look in the Pigeon Hole Pointer for instructions as to what to do in various situations. Knowing of the type allows in addition to get easily at the Methods and Properties through the applying of a period ( .Dot) ( intellisense ). Note this is a look up type list and may not be a guarantee that every offered thing is available – most will be typically.
Set Rng = Application.Range(strRef) ' EP Set: Setting to a Class will involve the use of an extra New at this code line. I will then have an Object referred to as an instance of a Class. At this point I include information on my Pointer Pigeon hole for a distinct distinguishable usage of an Object of the Class. For the case of something such as a Workbook this instancing has already been done, and in addition some values are filled in specific memory locations which are also held as part of the information in the Pigeon Hole Pointer. Wed will have a different Pointer for each instance. In most excel versions we already have a few instances of Worksheets. Such instances Objects can be further used., - For this a Dim to the class will be necessary, but the New must be omitted at Set. I can assign as many variables that I wish to the same existing instance
End Sub
Although the long string reference, strRef, looks daunting, I find this a robust way to reference a Range Object:
It gives me flexibility in the string build, and I have no confusion arising from where the code line might be... ( ... I reference the same Range Object, without generally any errors arising in the attempt, for the code line in any code Module )
Alan
' Rem Ref http://powerspreadsheets.com/excel-vba-range-object/
Bookmarks