3 respuestas en este tema

[cram]

Este es el mecanismo de comprobación para la existencia de datos en uno de mis forms de una aplicación comercial que me encuentro desarrollando.

La idea es evitar la aparición de mensajes de exclamación que avisan al usuario que falta un dato, en el cual el mismo debe dar 'OK', 'Cerrar?, o lo que sea, volver al form buscar cuál es el error, corregirlo y probar de nuevo.

Este se volvió uno de los lineamientos de mis aplicaciones. Una especie de estándar o norma que quiero que cumplan mis productos.

 

¿en qué consiste?

Hay varios controles que deben tener un dato (son obligatorios), además deben ser válidos. Junto con esta condición, es necesario que se cumplan otras (que no se ven aquí). Para esto "ato" este procedimiento al evento OnChange de cada control de edición que quiero comprobar. El control cambiará de color en caso de faltar, en caso de estar bien, y en caso de haber error. Además, se habilita o deshabilita el control que permite terminar la transacción.

 

Pero lo que más quiero mostrar es el ahorro de codificación y de dos variables al notar una pequeña relidad.

php

// btAceptar es de tipo TButton, forma parte de los controles del form TfrmCompra
// y acepta los datos para concluir la registración de la compra.
btAceptar: TButton;
 
// valComprob es una variable de tipo entero se declara como privada en el form TfrmCompra.
ValComprob: Integer;
 
// la comprobación de habilitación de btAceptar (btAceptar.enabled) se realiza en varias partes:
// 1. al quitar un elemento de la lista de artículos (dsListaArt.Dataset.IsEmpty)
// 2. al identificar (definir) un proveedor (codprov <> 0)
// 3. al cambiar el valor de uno de los cuadros de edición (TEdit) para datos del encabezado de la factura
//    se incluye un disparador del evento en varios controles necesarios
//    como ser el número de la factura, el total de la compra, etc.
procedure TfrmCompra.Comprobar(Sender: TObject);
var
  AuxInt: Integer;
  AuxFloat: Double;
  Aceptar: Boolean;
begin
  if not (TEdit(Sender).Text = '')
  then
    begin
      if (TWinControl(Sender).Name = 'edNroFactura') or (TWinControl(Sender).Name = 'edNroRecibo')
        then Aceptar:=  TryStrToInt(TEdit(Sender).Text, AuxInt)
        else Aceptar:=  TryStrToFloat(TEdit(Sender).Text, AuxFloat);
      if Aceptar then
      begin
        if ValComprob and TWinControl(Sender).Tag <> TWinControl(Sender).Tag
          then ValComprob:= ValComprob + TWinControl(Sender).Tag;
        TEdit(Sender).Color:= clSkyBlue;
      end else
        TEdit(Sender).Color:= $001D39FE;
    end
  else
    begin
      TEdit(Sender).Color:= $00A6CAF0;
      if ValComprob and TWinControl(Sender).Tag = TWinControl(Sender).Tag
        then ValComprob:= ValComprob - TWinControl(Sender).Tag;
    end;
  btAceptar.Enabled:= (ValComprob = 1 + 2 + 4 + 8) and (codProv <> 0) and (not dsListaArt.Dataset.IsEmpty);
end;
 
Ahora bien, los controles comprobados por comprobar son:
edNroFactura,
edTotalNeto,
edTotalIVA,
edTotalFactura,
edNroRecibo (sólo se vuelve obligatorio cuando se registra el pago en el mismo acto)
 
edNroFactura y edNroRecibo son cadenas de caracteres numéricos que pueden ser comprobados como enteros,
aunque no necesariamente lo son, ya que no se los utiliza para cálculo alguno.
edTotalNeto, edTotalIVA y edTotalFactura son de tipo Double.
 
Silogismo aplicado:
todos los enteros están incluidos en los reales
edNroFactura y edNroRecibo son (corresponden a) números enteros
edNroFactura y edNroRecibo están incluidos en los números reales
 
// entonces se podría evitar algunas líneas y la declaración de dos variables
 
procedure TfrmCompra.Comprobar(Sender: TObject);
var
  AuxFloat: Double;
begin
  if not (TEdit(Sender).Text = '')
  then
    begin
      if TryStrToFloat(TEdit(Sender).Text, AuxFloat)
      then
        begin
          if ValComprob and TWinControl(Sender).Tag <> TWinControl(Sender).Tag
            then ValComprob:= ValComprob + TWinControl(Sender).Tag;
          TEdit(Sender).Color:= clSkyBlue;
        end
      else TEdit(Sender).Color:= $001D39FE;
    end
  else
    begin
      TEdit(Sender).Color:= $00A6CAF0;
      if ValComprob and TWinControl(Sender).Tag = TWinControl(Sender).Tag
        then ValComprob:= ValComprob - TWinControl(Sender).Tag;
    end;
  btAceptar.Enabled:= (ValComprob = 1 + 2 + 4 + 8) and (codProv <> 0) and (not dsListaArt.Dataset.IsEmpty);
end;

Saludos

[Nikolas]

interesante.

 

en mi caso, controlo la validez en el onkeypress de caja edit con el objeto sender y los datos obligatorios en el onclick de guardar los datos y desde ya que aparece un mensaje de error jeje

 

saludos

[Wilson]

Dos preguntas:

 

¿El botón aceptar está deshabilitado cuando se crea el form? ¿Si es así en que momento ejecutas el procedimiento "comprobar" para habilitar el botón?

 

Yo utilizo siempre un TActionList, lo que me permite asignar un procedimiento a múltiples controles (botones, items de menú principal o contextual, etc) y programo el evento OnUpdate de la acción para habilitar o deshabilitar automáticamente los controles que ejecutan la acción según se vayan cumpliendo las condiciones.

 

Saludos.

[cram]

Dos preguntas:

 

¿El botón aceptar está deshabilitado cuando se crea el form? ¿Si es así en que momento ejecutas el procedimiento "comprobar" para habilitar el botón?

 

Yo utilizo siempre un TActionList, lo que me permite asignar un procedimiento a múltiples controles (botones, items de menú principal o contextual, etc) y programo el evento OnUpdate de la acción para habilitar o deshabilitar automáticamente los controles que ejecutan la acción según se vayan cumpliendo las condiciones.

 

Saludos.

 

Sí, el botón está deshabilitado, y además se deshabilita con un nuevo registro (o transacción de registro de compra).

Interesante lo de usar OnUpdate. Hasta quizás sea más sencillo (a veces me complico algo las cosas) pero funciona de maravilla.

En varias partes se llama al procedimiento, lo dice en el comentario de varias líneas, ese que está enumerado.

TActionList utilizo para otras cosas, la verdad nunca para esto. Será cuestión de probar como queda.

 

interesante.

 

en mi caso, controlo la validez en el onkeypress de caja edit con el objeto sender y los datos obligatorios en el onclick de guardar los datos y desde ya que aparece un mensaje de error jeje

 

saludos

 

En este caso no hace falta usar OnKeyPress, ya que para el caso de los valores nétamente numéricos como el número de factura y el número de recibo, lo limito con la propiedad NumbersOnly habilitada (de ahí que siempre arrojará enteros, creo que olvidé decirlo).

Aparte se me hace un lío en el caso de que el usuario pulse un punto en vez de una coma o dos veces la coma, etc., ya que al permitir coma permito caracteres y en OnKeyPress, tengo que preguntar un poco más.

 

Saludos

Editado por cram, 14 mayo 2015 - 11:17 .