vba - sub - range(cells() cells())
¿Qué pasará con Office VBA? (5)
Están agregando soporte de VBA a la próxima versión de Office para Mac , así que sospecho que estará disponible por un tiempo.
La empresa en la que trabajo se ejecuta en hojas de Excel. Varias de esas hojas tienen alguna forma de código VBA incrustado. Les estoy haciendo algo de mantenimiento, pero se siente realmente anticuado.
¿Qué pasará con Office VBA?
¿Por qué Microsoft no ha lanzado un lenguaje de macro .NET incrustado para Office?
Yo diría que es hora de que te sumerjas en .NET.
Puede llamar a bibliotecas .NET desde Excel.
Bueno, soy un experimentado programador de .NET. Intenté usar Tools for Office, que es muy complicado de usar y requiere distribuir ensamblajes (LOL). No hay forma de que Finance or Delivery lo use. Nos reímos bien antes de ir a la desinstalación.
Probamos Google Docs, que fue sorprendentemente flexible, pero aún no tan poderoso como el de las macros de Excel. Microsoft se ha estancado desde 2000, y Google se está moviendo rápidamente, por lo que en unos pocos años las respuestas podrían ser diferentes. VBA en sí mismo es actualmente menos poderoso debido a todas las tonterías de seguridad.
Al final, todavía tengo un botón en su hoja para hacer lo que quieren, y pueden hacer cambios menores en el código si así lo desean. Es extraño que VBA sea el camino a seguir para algo que sospecho que usan todos los departamentos de finanzas del mundo.
Respuesta corta: probablemente ya estés bien por un tiempo.
Respuesta larga: VB6 (que es lo que realmente es VBA) es casi un lenguaje muerto, no compatible, actualizado por última vez hace una década con un IDE del mismo período. Solo está presente porque está integrado en Office y hay millones de aplicaciones de Office que dejarían de funcionar si se eliminara o cambiara VBA. Sin mencionar a millones de usuarios muy molestos.
Entonces, ¿cómo avanzar? ¿Se puede volver a implementar Office en el código administrado? ¿Microsoft quiere hacer eso en absoluto? ¿Van a hacer una ruptura de compatibilidad hacia atrás aún mayor que la cinta de opciones y simplemente descartar la noción de grabación de macro e interpretar el código incrustado? Simplemente no puedo ver a mis usuarios llevándose a VB.NET en Visual Studio, usando COM Interop y otras cosas.
Si tuviera que poner dinero en un resultado (y no me gustaría apostar mucho incluso entonces) estaría mirando el tiempo de ejecución de lenguaje dinámico y el hecho de que varios idiomas están en varios estados de preparación para ejecutarlo. Supongamos que el DLR, con algún reemplazo adecuado o envoltorio para el modelo COM de la aplicación Office, reemplazara el tiempo de ejecución de VB6. Además, supongamos que VBA se implementó como un lenguaje DLR. Ahora VBA heredado continuará ejecutándose, solo en un intérprete diferente (moderno, compatible) y en la negociación, podemos programar macros de Excel en Python, Ruby o cualquier otro lenguaje DLR que nos apetezca.
Pero esa es solo mi mejor conjetura, no tengo idea de si realmente va a ocurrir algo así o no. Sin embargo, me encantaría poder programar macros de Excel en Ruby.
Un poco encontré la misma línea de pensamiento ayer. Qué casualidad. De repente, el jefe de mi trabajo a tiempo parcial buscaba una aplicación de Excel que creé hace 3 años (abandoné la empresa en 2007 y volví a trabajar como empleado a tiempo parcial para aumentar mi trabajo a tiempo completo). Recuerdo que lo había convertido a una aplicación MS Access 2003; pero la aplicación debe actualizarse para cumplir con los requisitos más nuevos. Adivina qué, creo que ya me olvidé de VBA. No es el momento adecuado para volver y volver a aprender cosas desde cero. Estoy avanzando con C # 2.0 / 3.0. ¡Reconstruir esa aplicación MS Access 2003 con C # 3.0 será una gran experiencia de aprendizaje, estoy seguro!
@IainMH tiene razón ... "es hora de que te sumerjas en .NET"