Pregunta Es el . in. ¿Es necesario el flujo cuando está definido por .Cells?


Es ampliamente aceptado que esta no es la "mejor práctica".

dim rng as range
with thisworkbook    '<~~ possibly set an external workbook 
    with .worksheets("sheet1")
        set rng = .range(cells(2, 1), cells(rows.count, 1).end(xlup))
    end with
end with

Los dos Range.Cells propiedades que definen el alcance de la Objeto de rango se establecerá de manera predeterminada Propiedad ActiveSheet. Si esto no es Sheet1 (definido como el .Padre en el Con ... Fin Con declaración), la tarea fallará con,

Run-tim error '1004': Application-defined or object-defined error

Solución: uso .Cells no Cells. Caso cerrado.

Pero...

Es el . necesario en esto Objeto de rango definición cuando tanto el Range.Cells las propiedades heredan .Padre propiedad de hoja de cálculo que se define en Con ... Fin Con declaración?

¿Cómo puede esto,

dim rng as range
with thisworkbook    '<~~ possibly set an external workbook 
    with .worksheets("sheet1")
        ' define rng as Sheet1!A2 to the last populated cell in Sheet1!A:A
        set rng = .range(.cells(2, 1), .cells(rows.count, 1).end(xlup))  '<~~ .range
    end with
end with
debug.print rng.address(0, 0, external:=true)

... ser diferente de esto,

dim rng as range
with thisworkbook    '<~~ possibly set an external workbook 
    with .worksheets("sheet1")
        ' define rng as Sheet1!A2 to the last populated cell in Sheet1!A:A
        set rng = range(.cells(2, 1), .cells(rows.count, 1).end(xlup))  '<~~ range not .range
    end with
end with
debug.print rng.address(0, 0, external:=true)

Usamos .range cuando los parámetros que definen el alcance del rango son ambiguos; p.ej. .range([A1]) los A1 celda podría ser de cualquier hoja de cálculo y se establecerá de forma predeterminada Propiedad ActiveSheet sin el .. Pero, ¿por qué necesitamos hacer referencia al elemento principal de un objeto rango cuando el ámbito que lo define ha hecho referencia a su hoja de cálculo principal?


14
2018-04-02 01:32


origen


Respuestas:


Mi opinión es ligeramente diferente aquí.

 Es requerido. No siempre se puede controlar desde dónde el usuario puede ejecutar el código.

Por favor considere estos pocos casos de prueba

GUIÓN

Workbook tiene 2 hojas de trabajo. Sheet1 y Sheet2


PRUEBA 1 (ejecutándose desde un módulo)

Ambos códigos dan el mismo resultado

PRUEBA 2 (ejecutándose desde un área de código de hoja de Sheet1)

Ambos códigos dan el mismo resultado

PRUEBA 3 (ejecutándose desde un área de código de hoja de Sheet2)

'~~> This code fails
set rng = range(.cells(2, 1), .cells(rows.count, 1).end(xlup))

Conseguirás Application Defined or Object defined error

enter image description here

Y por lo tanto, siempre es recomendable calificar adecuadamente sus objetos para que el código pueda ejecutarse desde cualquier lugar


19
2018-04-02 06:16



No, el . no se requiere donde las referencias de celda dentro de los paréntesis están calificadas, a menos que el código esté en una Worksheet módulo. Dicho esto, es más rápido ejecutar set rng = .range(.cells(...), .cells(...)) de lo que es correr set rng = range(.cells(...), .cells(...)) así que incluyendo el . hace algo bueno.

Para Worksheet módulo, el . es requerido.


9
2018-04-02 04:10



La respuesta parece ser: solo si el código está ubicado en un objeto de hoja de cálculo. Sospecho fuertemente que esto se debe a que los objetos de la Hoja de trabajo son los únicos que son tanto extensibles como tienen una Range función. Cuando Range se llama desde una hoja de cálculo, ese objeto Range la función tiene alcance Cuando el código se encuentra en ThisWorkbook o en un módulo o clase de usuario, el Range función con el alcance más cercano disponible es el global Range objeto (suponiendo, por supuesto, que no hay un usuario definido Range función). Esa está ligada a la Application, cual tiene que Resuélvalo en función de los parámetros pasados ​​y reenvíe la llamada a la Hoja de trabajo correcta.


7
2018-04-02 01:53