Como reconocer el origen de la entrada de texto en un TEdit

[[movorack]]

Hola foro...

Tengo una duda con la cual me he roto la cabeza toda la mañana.

¿Como reconocer el origen de la entrada de texto en un TEdit?

En la empresa, manejamos unos fichos para establecer turnos de atención a los vehiculos... mientras los vehiculos están dentro del parqueadero, ellos tienen un unico ficho con el cual deben realizar todas las operaciones.

En el momento de llegar a una ventanilla, los conductores presentan el ficho para validar su ingreso y asi proceder con el pago (por ej).

La duda nace pq en el cuadro de dialogo que he hecho para reconocer el ficho o carnet he colocado un TEdit oculto (detras de un panel) con focus desde que se muestra el dialog. Cuando pasan el código por el laser, el lector USB envia los datos al TEdit para procesarlo... todo trabaja OK.

PERO... si en lugar de pasar el códígo de barras por el laser, cualquier usuario ESCRIBE desde el teclado el código del ficho o carnet, al presionar enter... realizará el mismo proceso que con el lector laser.

Esto es un problema de seguridad que los usuarios todavia no saben (ojala y no entren al club jajajaja)... si supieran se volarian la verificación de ficho (algunos conductores lo dejan en el carro, se lo prestan a otro... en fin... eso es parte de la seguridad que queremos implementar)... por eso la pregunta...

¿Como reconocer el origen de la entrada de texto en un TEdit?

Si alguien me puede ayudar... pls.

[delphi.com.ar]

Si el lector del cuál hablas funciona como emulador de teclado, dudo que puedas identificar la procedencia de la entrada. Una opción, que he utilizado alguna vez, es utilizar lectores que se comuniquen por el puerto serie, entonces tu manejas la entrada y la tienes bien identificada.

Saludos!

[[Chris]]

Hasta donde tengo entendido, estos periféricos funcionan emulando el tecleo físico de un usuario procedido por un ENTER. Dependiendo de cada marca y cada modelo, esto puede variar, pues algunos tienen sus propias APIs que puedes usar para evitar que tengas que trabajar a cómo tú lo estás haciendo actualmente.

Tengo como un flash de que en la API de Microsoft Windows existen rutinas que te ayudan a determinar si el "tecleo" fue virtual (Usado por ciertos dispositivos y llamadas a la API) o real (Hecho físicamente por el usuario). Por otro lado, si el periférico es USB es muy seguro que éste envie los "Key Strokes" al sistema directamente, por lo que Windows siempre los interpretará como tecleos reales.

Saludos.

[[movorack]]

Los dispositivos que uso emulan los keystrokes del teclado y envian a windows (no tienen api propia). Estos keystrokes son como estar tecleando directamente.

he intentado todo el dia con codigos y artilugios de aqui y de allá... por eso esperaba encontrar una solución.

Correción: Todavia... ESPERO... Que Dios ilumine a alguno de nuestros sabios

[rgstuamigo]

Has intentado a usar cualquiera de los evento (OnKeyPress ó OnKeyUp ó OnKeyown) del Edit en cuestion.Digo esto ya que los eventos del edit son solo implementados en el Lenguaje Delphi, si tu lector de codigo de barra, esta usando solo APIs para escribir en el Edit, los eventos anteriores nose van a ejecutar(en teoria ),caso contrario, no te servira..
Podrias hacer una simple prueba, coloca el siguiente codigo en el evento OnKeyPress del Edit;

Código Delphi [-]
procedure TForm1.Edit1KeyPress(Sender: TObject; var Key: Char); 
begin      
  ShowMessage('Hola');//<--Hay que probar si se ejecuta esto al leer con el laser . 
{Si no se ejecuta, pues ya sabemos por lógica que se escribio con el teclado y no con el lazer VICTORIA}
 {Caso contrario, no sirve, no tomar en cuenta mi IDEA , DERROTA Buscar Otra Alternativa.... }
end;

Espero se haya entendido la idea.
Saludos...

[The_Duke]

Puedes probar si el lector envía los caracteres uno a uno o si lo envía todos al mismo tiempo ya que si es así puedes hacer que después de cada tecleo se borren así si presionan más de una vez nunca aran el código con dichos eventods

[juanelo]

Que tal,
Pues a lo mejor pueda parecer algo burdo, pero debe de funcionar, mide el tiempo entre el primer "teclazo" y el ultimo, estoy seguro que por muy rapido que uno ingrese la clave, no lo hara mas rapido que el lector laser.
Puedes poner un parametro de "velocidad" de ingreso, si la diferencia entre el primero y el ultimo catacter de la clave es menor que este, pues casi seguro que fue via el lector laser, de otra forma, lo hizo un simple mortal .
Saludos.

[[movorack]]

hi... gracias a todos por sus aportes...

rgstuamigo... intente OnKeyPress y...

ShowMessage('Hola');

The_Duke... al parecer envia una a una las letras como si se tratara de una escritura con teclado...

juanelo... me agrada tu idea... pq si emula la escritura del teclado y lo hace full rapido... cosa que no podria hacer ningun "mortal"

mañana en la oficina intentaré... por ahora... voy a cerrar las ventanitas

[Neftali [Germán.Estévez]]

Creo que una opción sencilla, y que alguna vez ha salido por aquí, es la que propone Juanelo.

Independientemente que que puedas probar otras.

[[Crandel]]

Independiente de detectar el origen de la pulsación, yo no eliminaría la opción de la escritura por teclado.

Siempre puedes tener problemas con el lector, ya sea una mala lectura como un daño físico y tu sistema se trabaría.

Yo por mi parte intentaría implementar un sistema de seguridad que valide el número ingresado, independiente de donde provenga.

[rgstuamigo]

Empezado por movorack

hi... gracias a todos por sus aportes...

rgstuamigo... intente OnKeyPress y...

The_Duke... al parecer envia una a una las letras como si se tratara de una escritura con teclado...

Intenta cambiarlo dentro del evento OnKeyUp y nos cuenta como te va, aunque la idea de Juanelo es buena..
Saludos...

[[movorack]]

Nuevamente, gracias por sus comentarios y aportes... me han servido un montón.

les cuento... evalué el resultado de OnKeyPress, OnKeyUp y OnKeyDown... en todos los manejadores el resultado era el mismo... coloqué un listbox para agregar cada caractér como viniera desde el lector... este fué el resultado...



Los resultados sombreados son pulsaciones ordinarias de teclado.

Entonces me dí a la tarea de medir el tiempo de pulsaciones ordinarias y la lectura del laser...

estos son los resultados para fichos y carnets... nuevamente, la zona sombreada en azul son pulsaciones ordinarias de teclado...





en la medición (milisegundos)... los resultados son satisfactorios.

Digitación de Fichos (Manual)...
Menor: 00.219
Mayor: 00.406

Lectura de Fichos (Laser)...
Menor: 00.015
Mayor: 00.050

Digitación de Carnets (Manual)...
Menor: 02.000
Mayor: 04.016 y más

Lectura de Carnets (Laser)...
Menor: 00.100
Mayor: 00.125

Me inclino mucho por esta opción...

--> por lo que dices crandel...

... yo no eliminaría la opción de la escritura por teclado.

Siempre puedes tener problemas con el lector, ya sea una mala lectura como un daño físico y tu sistema se trabaría...

En las imágenes puedes ver un botón para omitir la lectura laser... al presionarlo, el programa solicita autorización administrativa (supervisor) para continuar... además que el cuadro de dialogo puede deshabilitarse por parametros para casos fortuitos.

Nuevamente gracias a todos... por sus aportes y comentarios...

Pst: Yo confiaba en Dios que nos daria una solución.

[Gregory Mazon]

Porque no le agregas un digito verificador (calculado), despues de leer tu codigo de barras, obvio este que no este visible en la tarjeta asi los usuarios no sabran nunca el codigo completo, y de esta forma solo cambias la ideologia de tu seguridad

[[movorack]]

... lo del digito verificador calculado suena bien... yo le tengo un digito de identificación que antecede al tipo de documento... ficho (2) o carnet (1)... pero... los carnets pertenecen a conductores de tractocamiones que se deplazan por tooooda Colombia (mi hermoso y bello pais ) y aveces llegan hasta Venezuela o Ecuador... imaginate volver a hacer los casi 5.000 carnets que se han emitido y entregarselos a sus respectivos dueños?