Hola Iván,
Post by Ivande todas formas solo algo parecido a una 'reflexion' =>
aunque la consulta de OP queda resuelta con tu solucion y ademas lo
que voy a comentar posiblemente no tenga nada que ver con su caso...
Ojo, un segundo que aclaro unos detalles, porque a fin de cuentas todo
siempre tiene que ver con el todo.
Debe concretarse que la respuesta que dí no era la *solución al
problema*
de quien abrió la consulta, sino que era la *respuesta a la pregunta que se
formuló*, que no es lo mismo (aunque a bote pronto pueda parecer confuso, en
parte por mi culpa, ya que dí por sentado que la solución ya se le había
comunicado).
Por esto aclaro que él o ella preguntó con los siguientes términos:
[···]
Post by IvanNecesito que no se dispare el evento Validating de un Texbox cuando
este tiene el foco y se cierra su formulario pulsado la X de
ControlBox.
[···]
Y la única forma, que sepa yo, para *evitar la notificación del evento*
es como expuse, subclasificando el formulario.
JOMIJIMO no aclara en ningún momento qué es lo que se realiza dentro de
la validación, para que nosotros podamos asesorarle teniendo en
consideración si está usando el evento adecuado o no, ni si lo está usando
debidamente.
Tampoco nos pidió que se pudiese cerrar el formulario a pesar de
ejecutarse el evento '_Validating', cosa que también es posible de realizar.
Si el control activo establece e.Cancel = True dentro de la validación
al cerrar el formulario, el evento '_FormClosing' recibe en su parámetro 'e'
la propiedad '.Cancel' establecida en True. Por consiguiente (un ejemplo
bobo):
'*********************
Private Sub Form_FormClosing(ByVal sender As Object, ByVal e As System...
If e.Cancel = True Then 'Un control lo ha cancelado previamente
e.Cancel = MessageBox.Show("Existen datos no válidos. " _
& "¿Cerramos igualmente?", "FormClosing", _
MessageBoxButtons.YesNo, MessageBoxIcon.Exclamation) _
= Windows.Forms.DialogResult.No
End If
End Sub
'*********************
Como se puede apreciar, si el usuario responde "Sí", se restablece el
argumento de cancelación, permitiendo que el formulario prosiga el curso de
cierre, sino, el cierre queda cancelado tal como lo había solicitado el
evento de validación del control que canceló la pérdida de su foco, y
retendrá el foco de entrada.
Pero repito, en este caso no se estaría evitando que el evento
'_Validating' sea notificado y ejecutado su código asociado, simplemente
sería ignorado después de haberse ejecutado su código.
Post by Ivanbueno, lo mismo estoy diciendo una de mis 'chorradas' [ si es que se
me entiende ;-) ..} pero no me 'importaria' saber tu opinion
No creo que sea ninguna chorrada lo que comentas.
Siguiendo pues la reflexión, te explico mi punto de vista y verás que en
el fondo estamos más o menos bastante de acuerdo:
fue en VB6 que apareció el evento '_Validate' bajo un epígrafe de
"mejora en la validación de datos" para los controles intrínsecos. Fue un
evento (en conjunción con la nueva propiedad 'CausesValidation') *diseñado
específicamente para poder cancelar la pérdida del foco del control bajo
determinadas circunstancias*, ya que anteriomente había el inconveniente de
que si se pretendía restablecer el foco desde el '_LostFocus' del mismo
control en un caso de datos no válidos, se ejecutaba igualmente el evento
'_GotFocus' del control al que se había salido, y debía trampearse, por
ejemplo para que veas la idea antiguamente podía hacerse así:
'--------------------
Dim m_CancelFocus As Integer
Private Sub Text1_LostFocus()
If Condición Then
m_CancelFocus = True
Text1.SetFocus
End If
End Sub
Private Sub Text2_GotFocus()
If m_CancelFocus = True Then
m_CancelFocus = False
Exit Sub '···>>>
End If
'Código ejecutable del evento
'...
End Sub
'--------------------
Como además puedes notar, tampoco se podía usar 'ActiveControl.SetFocus'
en el '_LostFocus', ya que en esa línea el foco de entrada ya lo tiene el
otro control, aunque todavía no ha sido notificado su '_GotFocus'.
En verdad, me atrevo a decir que el 98% de los casos en los que se
impone una cancelación de pérdida del foco obedecen a un mal diseño e
implementación conceptual. Pocos casos lo justifican, y sinceramente, ahora
no se me ocurre ninguno a excepción de una solicitud explícita por parte de
un cliente. No se puede atentar contra el libre albedrío del usuario
impidiéndole decidir a su antojo el orden de introducción de la información,
ya que si realmente fuese necesario establecer un orden secuencial, hay
mecanismos en forma de asistentes donde el usuario no puede avanzar al
siguiente dato de entrada hasta la validez del corriente, dándole la
posibilidad de retroceder o cancelar el proceso en cualquier momento.
De todas formas reconozco que es muy general, cada caso debe ser
analizado independientemente y considerando todos sus requisitos y
parámetros de entrada. Espero que quede claro que no estamos hablando de
paradigmas, sino de implementaciones en base a necesidades reales, porque si
se me permite una pequeña analogía algo estúpida, la acción "abofetear"
puede resultar inadecuada en el caso de 'Maria Teresa de Calcuta' y por
inmerecido ser excesivo, pero, esa misma acción, aplicada sobre el caso
'Charles Manson' resultaría francamente insuficiente.
Por estos motivos el ahora equivalente '_Validating' debería utilizarse
de la misma forma que en el clásico, única y exclusivamente para evaluar y
determinar si será necesario cancelar la pérdida del foco, nunca para una
acción, como por ejemplo dar formato al campo, o realizar un cálculo de
operandos para mostrarlo en otro campo, o realizar una actualización en una
base de datos ni nada que se le asome, solamente para verificar y cancelar
la pérdida si correspondiese.
Si no se contempla la posibilidad de cancelar la pérdida del foco (y
déjame insistir en que debería estar muy bien justificado), la validación y
acciones deben realizarse en el evento '_LostFocus' de toda la vida, como
por ejemplo el almacenamiento interno temporal, salvar una copia de
seguridad del borrador de la información corriente, o preprocesar cálculos
internos después de comprobar la validez, al perder el foco.
Entonces, ya que a resultaría adecuado no impedir al usuario "circular
libremente" por campos habilitados, simplemente se le debe "notificar
visualmente" que falta información, o que ésta es incorrecta, *por si le
place* corregirlo antes de proseguir, pero nunca imponerle la obligación de
corregirlo para autorizarle a pasar a otro campo.
Tampoco, bajo mi punto de vista como «usuario de una aplicación
informática» en lugar de como desarrollador, no me agradan las aplicaciones
que no me avisan hasta el final de todo el proceso de que me falta algo o
que simplemente es incorrecto, con el habitual agravante que el validador
examina campo por campo y cuando encuentra uno no válido lo notifica y le
establece el foco del teclado para corregirlo, ¿y qué pasa cuando hay más de
uno incompletos y/o no válidos?, ...pues que dan ganas de estrangular a
alguien por no tenerlos todos identificados en la notificación (que es algo
que tampoco me gusta, porque sobrepasa la capacidad de atención del usuario
estándar, raramente leen un sólo mensaje, menos leerán una enumeración de
los campos incorrectos).
Para ello, me encanta la idea del 'ErrorProvider', relativamente
discreto pero suficientemente llamativo. El usuario sabrá inmediatamente que
deja pendiente un campo requerido que más adelante volverá a requerir su
antención antes de dar aceptación a la entrada de datos, donde se le concede
la libertad de elegir el momento de su corrección, o la cancelación del
proceso de entrada, o la posibilidad de almacenarlo como borrador para
finalizarlo con posterioridad.
Como nota personal, el borrador es una funcionalidad de vital
importancia a mi parecer, uno nunca sabe cuando se dispondrá de toda la
información, y no veo ninguna necesidad de tener que completar forzosamente
el proceso de entrada en una tacada, es lógico que debería poderse iniciar
un registro, "aparcarlo" de forma temporal idefinidamente, y terminarlo
cuando sea factible. Un ejemplo: supón una secretaria que recoge los FAXes
recibidos durante los últimos días con los datos fiscales para la
contabilidad referentes a nuevos proveedores y clientes, va introduciendo
cada uno, inicia una ficha nueva, teclea la información, así uno tras otro.
Pero llegados al CIF de uno de esos FAX, detecta que una parte del número es
ilegible, decide llamar por teléfono pero en la ciudad de ese proveedor es
día festivo, qué debe hacer entonces, ¿descartar el trabajo que ya tenía
realizado?, no, lo almacenará como borrador y mañana consultará el dato y
finalizará el registro.
Por suerte y por desgracia he experimentado los dos tipos de gestión de
la interfaz de usuario, el que bloquea el proceso hasta que le dan lo que
quiere (es decir, solamente te da dos opciones, o "te inventas" un dato para
que calle un rato y sigues con otra cosa, o cancelas todo el proceso
efectuado hasta el punto actual y te acuerdas de la familia del
programador), y el que va avisando 'gota a gota' cada vez que intentas una
aceptación. En un caso por exceso, y en el otro por defecto, ambas son una
interfaz mal gestionada, para mis gustos personales y con total empatía con
el usuario. Para mí, como usuario es inaceptable, y como desarrollador, de
cara al usuario, es indecoroso.
Recuérdese, de ningún modo es un paradigma (y favor de nadie tomárselo
tampoco como pedancia), es solamente una opinión sobre un punto de vista,
cada cual debe analizar cada situación concreta, cuya implementación es
dependiente de los requisitos y la índole de los datos que deberán
gestionarse.
--
Saludos
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
( ! ) Respuestas precedentes en Google:
http://groups.google.com/group/microsoft.public.es.dotnet.vb
( i ) Temperancia en el foro:
http://support.microsoft.com/default.aspx?scid=fh;ES-ES;newsreglas
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -