eventos

Hombreee, no te pases! ;-)

Es cierto que migrar una aplicación de vb6 a vb.net no es
inmediato, pero la dificultad mayor es pasar de ado a
ado.net, y nadie obliga a hacerlo. El lenguaje no es
compatible, pero el aprendizaje para un usuario de vb es
muy sencillo. ¿Me equivoco?. Hay muchas cosas en vb.net
que hacen más sencillo migrar desde una aplicación vb6,
que por ejemplo a c#.

Menos mal que no dejan en mis manos el diseño de vb.net.
Yo habría eliminado todas estas cosas:

- Módulos
- Eventos no basados en delegado
- WithEvents
- Modos Explicit Off y Strict Off(mi única duda)
- Parámetros opcionales
- Librerías Visual Basic

Y creo que en la próxima versión se harán más
concesiones. ¿Que te parece lo de volver a la instancia
predeterminada de Form?. ¿Otra oportunidad para que los
usuarios sigan sin comprender lo que es una instancia, ni
saber como comunicar objetos?. ¿Y que tal lo de volver a
los arrays de controles?.

Es cierto que migrar una aplicación de vb6 a vb.net no es
inmediato, pero la dificultad mayor es pasar de ado a
ado.net, y nadie obliga a hacerlo. El lenguaje no es
compatible, pero el aprendizaje para un usuario de vb es
muy sencillo. ¿Me equivoco?. Hay muchas cosas en vb.net
que hacen más sencillo migrar desde una aplicación vb6,
que por ejemplo a c#.

Si, el aprendizaje puede ser mas rapido que C# pero arrastra todos los malos
habitos que la gente tenia con VB6.

Menos mal que no dejan en mis manos el diseño de vb.net.
Yo habría eliminado todas estas cosas:

- Módulos

Los modulos estan bien, lo que yo les habria quitado es que se
"autoimportaran" en todo el proyecto. O sea, tener clases con todos metodos
Shared para hacer ciertas cosas no esta mal.

- Eventos no basados en delegado

Coincidimos en esto.

- WithEvents

Por mi WithEvents puede quitarse, pero si dejando el Handles. Handles tiene
la ventaja sobre AddHandler que te permite ver directamente en la definicion
del metodo a que eventos y controles esta asociado sin tener que estar
buscando por todo el codigo los AddHandler. Ademas funciona sin problemas en
la mayoria de los casos.

- Modos Explicit Off y Strict Off(mi única duda)

Option String On y Option Explicit On son las dos primeras lineas que
siempre escribo, ademas de tenerlo como predeterminado.

- Parámetros opcionales

Algunas veces son mas comodos si son varios los parametros opcionales porque
permiten que se pase cualquier combinacion de parametros (esto requeriria
muchos metodos con sobrecarga).

- Librerías Visual Basic

Totalmente de acuerdo. Si algo se puede hacer usando el framework, para que
hacerlo con la libreria de VB (que en muchas partes lo unico que hace es
comprobar parametros y llamar a su par del framework).

¿Que te parece lo de volver a la instancia predeterminada de Form?

Es la peor idea que han podido tener. Cualquier buen programador en VB6 no
las usaba, ¿por que hacerlo ahora?.

¿Y que tal lo de volver a los arrays de controles?.

No se como es que se esta implementando eso (no he visto mucho de Whidbey)
pero aunque por el lado de los eventos no es necesario, permite simpliflicar
algunas tareas que requieren recorrer ciertos controles y no todos.

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo

O sea que por lo que veo estamos completamente de acuerdo, salvo matices
mínimos. :-)

Estoy completamente de acuerdo con que el principal problema de vb.net es
que da facilidades para seguir haciendo mal las cosas.

Los modulos estan bien, lo que yo les habria quitado es que se
"autoimportaran" en todo el proyecto. O sea, tener clases con todos

metodos

Shared para hacer ciertas cosas no esta mal.

Es decir que habrías eliminado los módulos. Habrías dejado clases con todos
los miembros shared. Es decir la opción de C#. Además, es mucho más
"elegante" trabajar con un lenguaje en que realmente todo sean objetos, sin
funciones globales ni nada similar. Solo por esa bobada, no puede decirse de
vb.net que sea un lenguaje orientado a objetos puro, cosa que si puede
decirse de c#.

Por mi WithEvents puede quitarse, pero si dejando el Handles. Handles

tiene

la ventaja sobre AddHandler que te permite ver directamente en la

definicion

del metodo a que eventos y controles esta asociado sin tener que estar
buscando por todo el codigo los AddHandler. Ademas funciona sin problemas

en

la mayoria de los casos.

No tengo clara la ventaja de saber que evento representa realmente un
método. Al fin y al cabo, si la asignación debe hacerse en tiempo de
ejecución, Handles no puede establecerse a priori. En general, precisamente
los delegados especifican lo que se quiere hacer, sin preocuparse sobre qué
debe hacerse. Pero el principal defecto de WithEvents es no poder aplicarse
sobre arrays, además de necesitar ser globales. Creo que la opción de C# en
vs.net 2003: ayuda de intellisense para generar el método del evento, es
mucho más funcional. Tal vez una mejora interesante, sería hacer que vs.net
permitiese elegir entre que el diseñador genere WithEvents o AddHandler.

> - Parámetros opcionales

Algunas veces son mas comodos si son varios los parametros opcionales

porque

permiten que se pase cualquier combinacion de parametros (esto requeriria
muchos metodos con sobrecarga).

Pero a cambio obliga a tener mucho cuidado con no repetir ninguna
sobrecarga. No siempre es evidente cuando un parámetro Optional produce un
conflicto con una sobrecarga. Pero es cierto que son útiles llamando a
componentes COM. Compatibilidad, como siempre. También puede ser útil Strict
Off para acceder a objetos COM, aunque me pese decirlo :-)

> ¿Y que tal lo de volver a los arrays de controles?.

No se como es que se esta implementando eso (no he visto mucho de Whidbey)
pero aunque por el lado de los eventos no es necesario, permite

simpliflicar

algunas tareas que requieren recorrer ciertos controles y no todos.

Pero realmente uno puede incluir, por código, todos los controles que crea
conveniente en un array ordinario. No veo ninguna utilidad en los arrays de
controles, que obligan a un array de un solo tipo de control. Además, el
problema de siempre, se dan facilidades para que la gente siga sin
comprender el funcionamiento de las cosas. Lo que yo haría simplemente, es
dejar que en tiempo de diseño, se pueda asignar controles a un array, un
array ordinario, no un array de controles. Eso, añadido a las posibilidades
que ofrecerán los genéricos, me parece mucho mejor opción.

Juan Carlos Badiola
MVP - C#

Es decir que habrías eliminado los módulos.

Digamos que si. Lo que me gusta mas a mi es algo como las nuevas clases
static del C#.

No tengo clara la ventaja de saber que evento representa realmente un
método.

Lo que tiene para mi es que hay una asociacion mas directa y mas facil de
ver entre el objeto al que pertenece el evento y el metodo. Tiene sus
limitaciones pero me parece practico para lo que es manejo de eventos de
controles. De todas formas siempre puede usarse AddHandler.

Pero a cambio obliga a tener mucho cuidado con no repetir ninguna
sobrecarga. No siempre es evidente cuando un parámetro Optional
produce un conflicto con una sobrecarga. Pero es cierto que son
útiles llamando a componentes COM. Compatibilidad, como siempre.
También puede ser útil Strict Off para acceder a objetos COM, aunque
me pese decirlo :-)

Nada de sobrecarga en metodos con parametros opcionales por favor ;). O se
usa un estilo o el otro, pero nada de mezclarlos porque ahi es donde
empiezan los problemas.

Lo que yo haría simplemente, es dejar que en tiempo de diseño, se pueda
asignar controles a un array, un array ordinario, no un array de
controles.

Como te decia, no se como se esta implementando eso y yo me referia a algo
como lo que tu comentas, o sea que el diseñador permita agrupar controles en
un arreglo o algo asi.

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo