Ir al contenido


Foto

Silogismo aplicado

codificación lógica delphi pascal comprobación

  • Por favor identifícate para responder
3 respuestas en este tema

#1 cram

cram

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 824 mensajes
  • LocationMisiones, Argentina

Escrito 13 mayo 2015 - 11:08

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
  1. // btAceptar es de tipo TButton, forma parte de los controles del form TfrmCompra
  2. // y acepta los datos para concluir la registración de la compra.
  3. btAceptar: TButton;
  4.  
  5. // valComprob es una variable de tipo entero se declara como privada en el form TfrmCompra.
  6. ValComprob: Integer;
  7.  
  8. // la comprobación de habilitación de btAceptar (btAceptar.enabled) se realiza en varias partes:
  9. // 1. al quitar un elemento de la lista de artículos (dsListaArt.Dataset.IsEmpty)
  10. // 2. al identificar (definir) un proveedor (codprov <> 0)
  11. // 3. al cambiar el valor de uno de los cuadros de edición (TEdit) para datos del encabezado de la factura
  12. //    se incluye un disparador del evento en varios controles necesarios
  13. //    como ser el número de la factura, el total de la compra, etc.
  14. procedure TfrmCompra.Comprobar(Sender: TObject);
  15. var
  16.   AuxInt: Integer;
  17.   AuxFloat: Double;
  18.   Aceptar: Boolean;
  19. begin
  20.   if not (TEdit(Sender).Text = '')
  21.   then
  22.     begin
  23.       if (TWinControl(Sender).Name = 'edNroFactura') or (TWinControl(Sender).Name = 'edNroRecibo')
  24.         then Aceptar:=  TryStrToInt(TEdit(Sender).Text, AuxInt)
  25.         else Aceptar:=  TryStrToFloat(TEdit(Sender).Text, AuxFloat);
  26.       if Aceptar then
  27.       begin
  28.         if ValComprob and TWinControl(Sender).Tag <> TWinControl(Sender).Tag
  29.           then ValComprob:= ValComprob + TWinControl(Sender).Tag;
  30.         TEdit(Sender).Color:= clSkyBlue;
  31.       end else
  32.         TEdit(Sender).Color:= $001D39FE;
  33.     end
  34.   else
  35.     begin
  36.       TEdit(Sender).Color:= $00A6CAF0;
  37.       if ValComprob and TWinControl(Sender).Tag = TWinControl(Sender).Tag
  38.         then ValComprob:= ValComprob - TWinControl(Sender).Tag;
  39.     end;
  40.   btAceptar.Enabled:= (ValComprob = 1 + 2 + 4 + 8) and (codProv <> 0) and (not dsListaArt.Dataset.IsEmpty);
  41.  
  42. Ahora bien, los controles comprobados por comprobar son:
  43. edNroFactura,
  44. edTotalNeto,
  45. edTotalIVA,
  46. edTotalFactura,
  47. edNroRecibo (sólo se vuelve obligatorio cuando se registra el pago en el mismo acto)
  48.  
  49. edNroFactura y edNroRecibo son cadenas de caracteres numéricos que pueden ser comprobados como enteros,
  50. aunque no necesariamente lo son, ya que no se los utiliza para cálculo alguno.
  51. edTotalNeto, edTotalIVA y edTotalFactura son de tipo Double.
  52.  
  53. Silogismo aplicado:
  54. todos los enteros están incluidos en los reales
  55. edNroFactura y edNroRecibo son (corresponden a) números enteros
  56. edNroFactura y edNroRecibo están incluidos en los números reales
  57.  
  58. // entonces se podría evitar algunas líneas y la declaración de dos variables
  59.  
  60. procedure TfrmCompra.Comprobar(Sender: TObject);
  61. var
  62.   AuxFloat: Double;
  63. begin
  64.   if not (TEdit(Sender).Text = '')
  65.   then
  66.     begin
  67.       if TryStrToFloat(TEdit(Sender).Text, AuxFloat)
  68.       then
  69.         begin
  70.           if ValComprob and TWinControl(Sender).Tag <> TWinControl(Sender).Tag
  71.             then ValComprob:= ValComprob + TWinControl(Sender).Tag;
  72.           TEdit(Sender).Color:= clSkyBlue;
  73.         end
  74.       else TEdit(Sender).Color:= $001D39FE;
  75.     end
  76.   else
  77.     begin
  78.       TEdit(Sender).Color:= $00A6CAF0;
  79.       if ValComprob and TWinControl(Sender).Tag = TWinControl(Sender).Tag
  80.         then ValComprob:= ValComprob - TWinControl(Sender).Tag;
  81.     end;
  82.   btAceptar.Enabled:= (ValComprob = 1 + 2 + 4 + 8) and (codProv <> 0) and (not dsListaArt.Dataset.IsEmpty);

Saludos

(b)


  • 0

#2 Nikolas

Nikolas

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 604 mensajes
  • LocationMar del Plata / Bs As / Argentina

Escrito 13 mayo 2015 - 07:33

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


  • 0

#3 Wilson

Wilson

    Advanced Member

  • Moderadores
  • PipPipPip
  • 2.137 mensajes

Escrito 13 mayo 2015 - 08:31

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.


  • 0

#4 cram

cram

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 824 mensajes
  • LocationMisiones, Argentina

Escrito 14 mayo 2015 - 11:13

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. :wink:

 

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 .

  • 0





Etiquetado también con una o más de estas palabras: codificación, lógica, delphi, pascal, comprobación