2012-09-14 15 views
5

Para esta pregunta, me refiero a los post de abajo para aclarar a mí mismo:
Why is my conditional format offset when added by VBA?.Elija, .Activesheet, .Activecell etc ...

En muchos, muchos mensajes que veo en estos días, se admiten OP de silencio utilizar. Activar,. Seleccionar,. Desactivar, etc., mientras que son una puerta abierta a posibles errores (más a menudo causados ​​por los usuarios finales).
El código a veces incluso es compatible.

Mi pregunta: ¿Hay alguna situación válida en la que usaría cualquiera de estos enunciados sin alternativas directas disponibles que detectaran los errores típicos resultantes de estos stmts?

Me refiero a dinámicas soluciones que en mi opinión son una necesidad en el desarrollo de Excel. Personalmente, en más de 6 años no recuerdo un solo caso donde lo necesité; parece ser siempre una de las peores opciones disponibles. En mi compañía anterior, era una regla silenciosa no usarla nunca y solo mejoraba mi VBA (y la del usuario final). Por qué creo esta pregunta es porque creo que es útil hacer que los recién llegados a VBA sean conscientes de los riesgos que corren al usar estas declaraciones (por la experiencia de riesgos comprobados cuando los Usuarios finales hacen algo inesperado, al final no no tengo ningún afecto con VBA) y proponer alternativas directas (no voy a decir que siempre hice eso antes que a mí mismo, pero siento en mis entrañas que hay algo mal con solo ofrecer soluciones rápidas a los monstruos que ya tienen errores).

Creo que cuando se permite silenciosamente (lo que mejora automáticamente en este caso), los desarrolladores de VBA crearán una cantidad cada vez mayor de herramientas de forma incorrecta (y así también los nuevos herederos heredarán el comportamiento, que también aprenderán de Stack Desbordamiento ya que Google devuelve los resultados que buscan (!)).
Si el desarrollador no sabe por qué "puede" usar un "seleccionar" y en qué situaciones es un error potencial, (s) que nunca debería usarlo en mi humilde opinión. Personalmente, podría usar la herramienta de selección en la ventana inmediata para hacer algunas comprobaciones rápidas sobre la definición de rango dinámico (modo de error), pero no en el código escrito.

El resultado hace que VBA al final sea aún más impopular de lo que ya es; el idioma se convertirá en víctima en caso de que surjan problemas (sin embargo, todavía es el "mejor" soporte de programación disponible para las aplicaciones de Excel y Access). He visto esto suceder muchas veces en una gran empresa donde VBA siempre es "mierda".

Esto es solo mi propia experiencia honesta.
No se trata de estar bien o mal; Estoy interesado en escuchar su punto de vista sobre la pregunta.

+0

Relevante: http://stackoverflow.com/questions/10714251/how-to-avoid-using-select-in-excel-vba-macros –

Respuesta

2

Existen algunos métodos en Excel que requieren Activar o ActiveSheet/ActiveWorkbook, etc. ya que he sido atrapado con problemas en alguna ocasión. El único que puedo recordar en este momento es la propiedad zoom. Zoom sólo afecta a la hoja que está actualmente activo en la ventana para hacer zoom todas las hojas que se necesitan algo así como

Sub SetZoom() 
Dim ws As Worksheet 
    Application.screenupdating = false 

    For Each ws In Worksheets 
     ws.Select 
     ActiveWindow.Zoom = 80 
    Next ws 

    Application.screenupdating = true 
End Sub 
+0

Ok, eso parecería válido. En este caso, usaría ActiveWindow conscientemente porque no tendría sentido realizar un zoom en una hoja inactiva. – Trace

3

Estoy de acuerdo con seleccionar y activar, pero no ActiveWorkbook, ActiveSheet y ActiveCell (Estoy de acuerdo que se abusa de ellos , pero no es que deban evitarse, per se). Definitivamente hay usos legítimos para aquellos. Tengo un programa que automatiza una "serie de relleno" que lo hace desde ActiveCell. Mi programa no puede predecir qué celdas se usarán; depende del usuario seleccionarlo. Eso es parte de la interfaz de usuario.

Sin embargo, hay tres situaciones en las que he tenido que usar Seleccionar (ahora cuatro que he leído sobre el zoom, pero nunca lo uso).

  1. Formato condicional. Existe un problema con el uso de Application.ConvertFormula, pero es peor que simplemente almacenar la selección, seleccionar la celda correcta, realizar la escritura y volver a seleccionar la selección anterior.
  2. Validación de datos. Misma razón.
  3. Formas. Desearía poder recordar los detalles, pero ha pasado demasiado tiempo desde que trabajé con Shapes. Había algo que no podía hacer sin seleccionar primero la forma.

El código de librado de Seleccionar y activar es una pelea noble.

+0

Estoy totalmente de acuerdo, SI el propósito es que un usuario explícitamente necesita seleccionar una celda en la que se realizarán las acciones. En todos los demás casos (que es el caso en un buen 99% por ciento del tiempo de lo que veo), buscaba los rangos para formatear/validar en un nivel dinámico que no requiere ser 'Activo'. ¿Por qué lo haría? Para el seleccionado, tampoco veo por qué el formato condicional y la validación de datos necesitan una selección ... Necesita una identificación clara del objeto, pero ¿por qué agregar se selecciona como requisito adicional? Para el formato de rango/celda, uso If Then/Select Case; después de todo, es programación. – Trace

+0

Bueno, la razón por la que lo publico es porque me molesta terriblemente cuando leo cosas como: Hojas (1) .Activar -> ActiveSheet.range (x, y) .Seleccionar etc ... Lo veo todo el tiempo últimamente , Me resulta difícil responder a eso, aunque lo haré si ayuda. En el enlace que menciono en mi publicación actual, la respuesta aceptada es: ActiveSheet.Range ("A1"). Activar Esto es solo pedir problemas ... Sin embargo, la siguiente persona que lea esto hará exactamente lo mismo. Y al final, VBA será "considerado" como un lenguaje que tiene muchos errores. Lo cual no tiene. – Trace

+1

re # 3, hay algunas instancias que he encontrado al aplicar formato a datos de series en gráficos, donde ocasionalmente es necesario seleccionar 'Seleccionar'. Parece que IMO es un error con Excel y no una característica de diseño. Word es un animal diferente, que depende mucho más del objeto Selection, y PowerPoint, también, hay algún tipo de operaciones que solo se pueden realizar cuando la aplicación y la diapositiva/forma son visibles (mientras que esto no significa estrictamente "activar ", es similar en algún sentido) –

1

Puede utilizar .Select para determinar cuál es la opinión de un usuario es después de ejecutar código - por ejemplo, si se crea un nuevo libro en su código, sin necesidad de utilizar Activate o Select el usuario no puede saber esto sucede.

frecuencia termino una larga operación de creación de un nuevo libro u otras manipulaciones de datos a gran escala con

FinalViewWorkbook.FinalViewSheet.Range("A1").Select 

Sólo para informar al usuario final sobre algo - "oh, esto creó un nuevo libro de informes!" etc.

+0

Eso me parece válido también. No para la manipulación de datos, sino como una indicación. Quizás deba establecerse un conjunto de reglas con respecto al uso de estas declaraciones. – Trace

0

creo que es importante en esta materia, para distinguir entre:

  • Active -algo: Sólo debe utilizarse si es absolutamente necesario conocer lo que el usuario está manejando en este momento. Según mi experiencia, esto generalmente es Validación de datos o Detección activa de hojas (por ejemplo, "Actualizar la hoja donde el usuario acaba de presionar un botón").
  • Selection: Un poco lo mismo que Active, solo use readingly. Es útil tanto para validación de datos como para trucos como "Interpretar el valor de celda como ruta y abrirlo en una nueva ventana de Explorador".
  • Select, Activate: En mi humilde opinión diferente de Selection, ya que en realidad cambia la celda seleccionada, etc. Hoja de uso Nunca esto para leer o escribir datos, ya que permite a un usuario de desordenar su programa con sólo hacer clic. A los usuarios les encanta hacer clic. Solo use esto para Zoom (vea la respuesta de @ user3357963) o limpie una vista después de que su código haya terminado de funcionar (vea la respuesta de @enderland). (No estoy seguro, pero creo que el manejo de PageView también requiere ActiveSheet).
  • Select, Activate la segunda: Si usted es nuevo en VBA y está aprendiendo a través de grabadora de macros, se encuentra una gran cantidad de código generado de esta manera: En primer lugar Range("A5").Select, entonces Selection.Value="NewValue". Únase a esto al Range("A5").Value="NewValue".
  • Offset: Personalmente, no tengo ningún problema al utilizar .Offset() - Nunca he tenido problemas con este comando. En cambio, creo que es una forma práctica de decir "La celda al lado de esto" sin tener que pasar "Hoja de esta celda en la fila y columna de esta celda + 1" cada vez.

En muchos, muchos mensajes que veo en estos días, se admiten OP de silencio para usar .Activate, .Elija, .Offset, etc ...

Estoy de acuerdo con esto. Aunque es más fácil dar la respuesta necesaria para que un código funcione, se debe desaconsejar el uso de ActiveCell.Value y similares. Esto será mucho más fácil si hay un hilo bien explicado con el que enlazar, ya que esto está siendo :-)

0

Desde mi punto de vista, con algunas excepciones, la única vez que debe usar Select es como una entrada del usuario, y solo después de una cuidadosa consideración de los requisitos alternativos de diseño/UI.

Por ejemplo, yo diría que no es aconsejable en general a confiar en Selection para permitir al usuario definir un objeto de área al este método mantiene ejecución dentro del código:

Dim myRange as Range 
Set myRange = Application.InputBox("Select your range", Type:=8) 

Sin embargo, si tiene que pedir a los usuarios para seleccionar una forma u objeto particular en la hoja de trabajo, entonces quizás es mejor dejarlos hacer un Selection (sin embargo, esto puede abrir una caja de Pandora de problemas sin un buen manejo de errores y lógica para evitar acciones de usuario no deseadas ...)

Aquí hay un ejemplo de una de esas excepciones que tengo en PowerPoint. Tengo algunos RibbonUI XML y VBA que agregan botones al menú contextual Shapes en PowerPoint y agrega botones similares a la propia cinta. Se trata de una interfaz de usuario perfecta que brinda al usuario final una experiencia más "nativa" con la aplicación: los usuarios desean poder hacer clic con el botón derecho en el gráfico y luego ejecutar algunos procedimientos macro contra ese gráfico o tabla seleccionada, etc. No lo hacen t desea presionar un botón para abrir un formulario de usuario y desplazarse por un cuadro de lista de nombres de formas genéricas o GUID.

El código de procedimiento tiene que examinar la Selection con el fin de manejar de forma adecuada para que pueda usar algo como abajo, donde

Sub UpdateOrEditSelection(update As Boolean) 
'This procedure invoked when user edits/updates a chart. 
Dim uid As Variant 
Dim sel As Selection 
Dim s As Integer 
Dim chartsToUpdate As Object 
Dim multipleShapes As Boolean 
Dim sld As Slide 
Set sel = ppPres.Windows(1).Selection 

If update Then 
    Set chartsToUpdate = CreateObject("Scripting.Dictionary") 
    Select Case sel.Type 
     Case ppSelectionShapes 
      For s = 1 To sel.ShapeRange.count 
       uid = sel.ShapeRange(s).Name 
       '.... 
       '... 
       '.. 
       '. 
      Next 
     Case ppSelectionSlides 
      For Each sld In sel.SlideRange 
       For s = 1 To sld.Shapes.count 
        uid = sld.Shapes(s).Name 
        '.... 
        '... 
        '.. 
        '. 

       Next 
      Next 
     Case ppSelectionText 
      s = 1 
      If sel.ShapeRange(s).HasTable Or sel.ShapeRange(s).HasChart Then 
       uid = sel.ShapeRange(s).Name 
       '.... 
       '... 
       '.. 
       '. 

      End If 
    End Select 
'.... 
'... 
'.. 
'. 

¿De dónde viene?

La grabadora de macros. Esencialmente, esta característica registra cada entrada de usuario literal: desplazamiento, selección, visualización, activación, propiedades predeterminadas, etc., hasta el punto de exceso. Si bien esto es a veces útil, sí fomenta código mal escrito por personas que no saben que es malo, pero no voy a extenderme en este punto que se ha hecho aquí:

How to avoid using Select in Excel VBA macros

¿Qué es mejor, conceptualmente?

Programa a los objetos directamente. Si simplemente está utilizando VBA para imitar las pulsaciones de teclas y los clics del mouse, lo está haciendo mal.

Excepciones:

he encontrado al aplicar el formato a los datos de series de gráficos, donde Select vez en cuando es necesario. Parece que IMO es un error con Excel y no una característica de diseño.

Otras aplicaciones (porque VBA no es única Excel):

  • Palabra es un animal diferente, que se basa mucho más en objeto Selection
  • En PowerPoint hay algún tipo de operaciones que se pueden solo se realizará cuando la aplicación y la diapositiva/forma sean visibles o estén a la vista. Si bien no suele ser necesario "seleccionar" nada, sí requiere un código más engorroso.

me encontré con este fragmento en mi Aplicación:

Set tb = cht.Shapes.AddTextbox(msoTextOrientationHorizontal, ptLeft, tBoxTop, ptWidth, ptHeight) 
    tb.Select '<--- KEEP THIS LINE OTHERWISE TEXTBOX ALIGNMENT WILL NOT WORK ## ## ## 

Y esto:

'PPT requires selecting the slide in order to export an image preview/jpg 
sld.Select 
ppPres.Windows(1).View.GotoSlide sld.SlideIndex 
sld.Shapes(1).Chart.Export imgPath, ppShapeFormatJPG 

Y esto, que trata de individuales Point objetos:

 pt.Select 
     pt.format.Line.Visible = msoTrue 
     pt.format.Line.Visible = msoFalse 
     pt.MarkerSize = pt.MarkerSize + 2 

esto no es una lista exhaustiva, solo algunos ejemplos de excepciones que Encontré. Si bien estos eran de PowerPoint, los cuadros de PowerPoint usan el mismo modelo de objetos que Excel, por lo que no me sorprendería que algunos de ellos también tengan que ser pirateados en Excel y en Word.

  • de Outlook: No hago mucho con Outlook, es muy parecido a la palabra y de hecho utiliza el modelo de objetos de Word en el Inspector, pero lo poco que hago con Outlook no se basan en cosas como ActiveInspector, etc.

ni Word o PowerPoint tienen una "grabadora de macros" más (en realidad, creo que la palabra podría, pero es tan maldita impotente como para ser inútil) y por el momento la mayoría de la gente hace cualquier desarrollo en otras aplicaciones, se han figurado la mayor parte de esto ya.

Cuestiones relacionadas