Problemas al presiona las teclas NumLock, CapsLock y BloqDes

[Sr.Scorpion]

Hola:

Quiero hacer una aplicacion con un StatusBar en donde me controle cuando esta encendida tanto el NumLock, CapsLock y BloqDes, la funcion la pongo en el OnKeyPress de la forma y resulta que cuando aprieto cualquiera de estas tres teclas no se activa el OnKeyPress.... que puede ser eso ???

Saludos

[jmariano]

Saludos!

Es mejor que uses el evento "OnKeyDown" que permite procesar teclas especiales como las que dices ("OnKeyPress" ocurre mas bien cuando se pulsan teclas normales de caracteres). Mira en la ayuda sobre los códigos virtuales de cada tecla ("Virtual key codes") y asi saber los que corresponden a las teclas que necesitas.

Chao!

[Sr.Scorpion]

Gracias.... como tu bien dices se actica el evento cuando presiono las teclas especiales.
El problema ahora es que el GetKeyState(VK_NUMLOCK) no me funciona siempre me da diferente de 0... en fin que no puedo controlar cuando esta o no activa..

Saludos

[dec]

Hola,

No es preciso que lo hagas en ningún evento específico, aunque puedes hacerlo así si es mejor o lo prefieres. Personalmente estoy utilizando un procedimiento para hacer lo que tú precisas y parte del procedimiento es este:


if GetKeyState(VK_CAPITAL) = 1 then
bEstado.Panels[8].Text := rsBloqMayus
else
bEstado.Panels[8].Text := '';
if GetKeyState(VK_NUMLOCK) = 1 then
bEstado.Panels[9].Text := rsBloqNum
else
bEstado.Panels[9].Text := '';
if GetKeyState(VK_SCROLL) = 1 then
bEstado.Panels[10].Text := rsScrolLock
else
bEstado.Panels[10].Text := '';

Puedo llamar al procedimiento desde "OnKeyDown", pero, también desde cualquier otro lugar, ya que en el mismo no se precisa de los parámetros que proporciona "OnKeyDown", por poner un caso. En cuanto a que no te funcione "VK_NUMLOCK"... lo único que puedo decirte es que en Delphi 7 y Windows Xp SP2 sí que funciona correctamente.

[jmariano]

Saludos!

Es que GetKeyState() devuelve la información, mas bien, a base de bits. Pero si al resultado de esta función le sumas simplemente 127, verás que te devolverá 0, cuando el NumLock está activo, y -1, cuando no lo está.


procedure TForm.FormKeyDown(Sender: TObject; var Key: Word;
Shift: TShiftState);
begin
if Key = VK_NUMLOCK then
case (GetKeyState(VK_NUMLOCK) + 127) of
0: ShowMessage('Activo'); // Permite usar el teclado numérico
-1: ShowMessage('Inactivo'); // Sólo funciona las teclas cursoras
end;
end;

[jmariano]

Saludos dec!

Justo vi tu respuesta despues de publicar la mia y quería preguntarte, ¿Te devuelve a ti "GetKeyState" un valor entre 0 y 1 al comprobar el NumLock? Porque tengo el mismo sistema operativo que tu (XP2) y la misma versión de Delphi (v7) y lo que me devuelve, en realidad, es un número entero negativo (-127 y -128, según esté o no activo), y al mirar la ayuda sobre esta función comenta que lo que cambia al activar o desactivar es el bit menos significativo (por eso da un número negativo).

Chao!

[dec]

Hola,


¿Te devuelve a ti "GetKeyState" un valor entre 0 y 1 al comprobar el NumLock?

Así es jmariano. Un 0 si la tecla en cuestión no está "activada" y un 1 si lo está...

[Sr.Scorpion]

Gracias a los dos por responderme..... problema resuelto. Eso si la funcion de DEC no me funciona, sigue como estaba antes... tuve que sumarle 127 como decia jmariano y asi fue como me trabajo.


Saludos y Gracias

[Sr.Scorpion]

Bueno al final tuve que hacer dos procedimientos... uno para el estado de las teclas y otro para cuando se presionan. En el evento OnShow de la Forma principal llamo al procedimiento KeyState.. el cual se ejecuta solamente una vez.


procedure TMain.KeyState();
begin
If GetKeyState(VK_NUMLOCK) = 1 Then
StatusBar.Panels[2].Style:= psText
else
StatusBar.Panels[2].Style:= psOwnerDraw;
If GetKeyState(VK_CAPITAL) = 1 Then
StatusBar.Panels[3].Style:= psText
else
StatusBar.Panels[3].Style:= psOwnerDraw;
If GetKeyState(VK_SCROLL) = 1 Then
StatusBar.Panels[4].Style:= psText
else
StatusBar.Panels[4].Style:= psOwnerDraw;
end;


y el otro procedimiento es KeyPressed que lo llamo solamente en el OnKeyDown y se le pasa como parametro la variable Key del OnKeyDown


procedure TMain.KeyPressed(Key: DWORD);
begin
If Key = VK_NUMLOCK then
if (GetKeyState(VK_NUMLOCK) + 127) = 0 Then
StatusBar.Panels[2].Style:= psText
else
StatusBar.Panels[2].Style:= psOwnerDraw;
If Key = VK_CAPITAL then
if (GetKeyState(VK_CAPITAL) + 127) = 0 Then
StatusBar.Panels[3].Style:= psText
else
StatusBar.Panels[3].Style:= psOwnerDraw;
If Key = VK_SCROLL then
if (GetKeyState(VK_SCROLL) + 127) = 0 Then
StatusBar.Panels[4].Style:= psText
else
StatusBar.Panels[4].Style:= psOwnerDraw;
end;


Si pueden mejorarlo pues bienvenido sea.... esto por lo menos soluciona el problema.

[roman]

No entiendo bien por qué la discrepancia en el funcionamiento. A mi me funciona como dice dec. Ahora, según la documentación, la comparación tendría que hacerse así:


if GetKeyState(VK_CAPITAL) and 1 = 1 then
...


Por otra parte, si lo que se desea es mostrar el estado de estas teclas en una barra de estado, yo me olvidaría del OnKeyDown y pondría un Timer que se ejecute cada 10 ms en donde haría la comprobación. De esta manera, sólo tienes que poner el código en un lugar y además el estado se reflejará correctamente aun cuando el estado de la tecla cambie por razones distintas a oprimir la tecla (al menos a mi me pasa cada tanto que la tecla NumLock se apaga luego de correr alguna aplicación).

// Saludos

[Sr.Scorpion]

Esa sentencia merece un aplauso y una reverencia..... esto hace que el procedimiento sea unico y no haya que introducirle parametros de tecla. Por lo tanto el procedimiento quedaria asi...

procedure TMain.KeyState();
begin
If GetKeyState(VK_NUMLOCK) and 1 = 1 Then
StatusBar.Panels[2].Style:= psText
else
StatusBar.Panels[2].Style:= psOwnerDraw;
If GetKeyState(VK_CAPITAL) and 1 = 1 Then
StatusBar.Panels[3].Style:= psText
else
StatusBar.Panels[3].Style:= psOwnerDraw;
If GetKeyState(VK_SCROLL) and 1 = 1 Then
StatusBar.Panels[4].Style:= psText
else
StatusBar.Panels[4].Style:= psOwnerDraw;
end;

roman... en cuanto a lo del Timer no me gusta mucho esa idea debido a que no tiene un efecto inmediato, es decir yo aprieto el CapsLock y se me demora 10 o 5 segundos en mostrarse ese cambio en mi aplicacion. Por lo menos en cuanto a mi respecta me gusta mas la onda del OnKeyDown, tiene un efecto mas inmediato. No obstante te agradezco que hayas intervenido en este post tu sentecia de verdad que me fue muy util

Saludos y Gracias

[roman]

roman... en cuanto a lo del Timer no me gusta mucho esa idea debido a que no tiene un efecto inmediato

:eek: ¿¿¿¡¡¡¡¡10 milisegundos no se te hace inmediato!!!!????? :eek:

Simplemente pon la propiedad Interval del timer en 10 (incluso 50 0 100 debe ser suficiente). Te aseguro que el efecto es inmediato.

// Saludos

[roman]

¿Has pensado que sucede si el usuario activa otra aplicación y estando en ella cambia el estado de alguna de estas teclas? ¿Crees que tu aplicación lo detectará? Haz la prueba.

// Saludos

[Sr.Scorpion]

Primero disculpa.... pense que habias dicho 10 segundos cuando en realidad eran 10 milisegundos. Bueno pensandolo bien no esta nada mal eso.... en esa parte tiene razon....
Ahora pregunto yo.... no seria mucho que a cada 10 mseg. se este ejecutando una accion, traiga esto como consecuencia algun error en la aplicacion o que esta intervenga en la ejecucion de otra o algo por el estilo ???

Saludos

[roman]

Ahora pregunto yo.... no seria mucho que a cada 10 mseg. se este ejecutando una accion, traiga esto como consecuencia algun error en la aplicacion o que esta intervenga en la ejecucion de otra o algo por el estilo ???

No te lo puedo asegurar pero dudo que hay problema. Si cada 10 ms exportaras una tabla de 100,000 registros seguramente habría algún problema pero el código que se ejecutaría en el OnTimer es sumamente rápido.

// Saludos

[Sr.Scorpion]

bueno pues entonces .... caso resuelto. Se queda el Timer que es mas abarcador que el OnKeyDown. Mil Gracias Roman por tus consejos.

Saludos

[dec]

Hola,

Vamos a ver... yo estoy utilizando el procedimiento tal como lo mostré arriba en un editor de texto (http://www.xeditor.tk): muestro en una barra de estado, entre otras cosas, el estado de las teclas que nos ocupan. Utilizo el evento "OnKeyUp" del formulario en que está el editor para llamar al procedimiento "ActualizarBarraEstado" y también llamo a dicho procedimiento cuando es preciso, por ejemplo, cuando se abre un archivo en el editor, pero también en otros lugares... pues bien, ¡no tengo en absoluto ningún problema, puede verse el editor funcionando, en lo que toca a ese aspecto, perfectamente!

[vtdeleon]

Saludos
dec, probando tu fabuloso editor encontre lo que comenta roman¿Has pensado que sucede si el usuario activa otra aplicación y estando en ella cambia el estado de alguna de estas teclas? Haciendo pruebas con el Caps, Numlock e Insert.:rolleyes:

[roman]

Utilizo el evento "OnKeyUp" del formulario en que está el editor para llamar al procedimiento "ActualizarBarraEstado" y también llamo a dicho procedimiento cuando es preciso, por ejemplo, cuando se abre un archivo en el editor, pero también en otros lugares

Este es precisamente el punto. De la forma que propongo sólo tienes que preocuparte en un lugar. En el XEditor, si oprimes CapsLock o NumLock estando tu aplicación inactiva, la barra de estado no se actualiza sino hasta que la vuelves a activar. De hecho, tal como lo tienes ahora podrías lograrlo usando una componente TApplicationEvents y poniendo el código en su evento OnIdle con lo cual la barra de estado estaría siempre al día al menos mientras esté activa la aplicación, pero el problema es cuando no está activa. Es un problema menor, tan sólo de apariencia, pero yo prefiero que la barra se actualice aun sin estar activa la aplicación.

// Saludos

[dec]

Hola,

roman, lo que dices sobre XEditor bien puede ser cierto, pero, seguro que habrá formas de arreglarlo. Yo, por mi parte, he preparado el siguiente ejemplo, muy sencillo, pero que, muestra a las claras cómo creo que puede solucionarse el asunto: salvando que, como tú dices, cuando la aplicación no esté activa no se dará cuenta de los cambios en las teclas especiales que nos ocupan: como digo, no creo que sea mayor problema solucionarlo, bien como tú dices, utilizando el evento "OnIdle" u otro parecido. En todo caso ahí está el ejemplo.

Actualización: Por cierto, roman, es posible que no uses XEditor hace tiempo ;) puesto que haciendo compruebo que bastaría hacer clic con el ratón en el mismo para que la barra de estado se actualizase, esto es, no sería preciso "comenzar a escribir". Tal vez todavía esta no sea la mejor solución, pero, no me descontenta para el caso.

Otra actualización: Soy estúpido a las veces. Acabo de probar lo que decías roman de utilizar el evento "OnIdle" y XEditor va de lujo así, mucho mejor, mucho más serio, como más pendiente de lo que le toca. He actualizado también el ejemplo adjunto de manera que también hace uso del evento susomentado. Gracias roman.

[vtdeleon]

Saludos
He actualizado también el ejemplo adjunto de manera que también hace uso del evento susomentado.????
He probado el "ejemplo", y no actualiza el statusbar cuando no esta activo:s,minimizado o en segundo plano.

[dec]

Hola,

vtdeleon, ¿seguro que bajaste la actualización del ejemplo? ¿Te fijaste si se hace ya uso del evento "OnIdle"? A mí me funciona, esto es, tal como cabe esperar del mencionado evento: no es que se actualize la barra de estado "automáticamente", pero, cuando se produce el evento.


Ahora, según la documentación, la comparación tendría que hacerse así:

if GetKeyState(VK_CAPITAL) and 1 = 1 then
...


¿De dónde sacaste la información roman? Si hay que hacerlo de ese modo, entonces, ¿porqué funciona con algo así simplemente?


if GetKeyState(VK_CAPITAL) = 1 then
...

[roman]

y no actualiza el statusbar cuando no esta activo:s,minimizado o en segundo plano.

Por eso digo que el OnIdle presenta el mismo "problema". Es por ello que me inclino por el timer.

// Saludos

[roman]

¿De dónde sacaste la información roman?

De aquí (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/userinput/keyboardinput/keyboardinputreference/keyboardinputfunctions/getkeystate.asp).

Según eso, el bit más alto indica si la tecla está oprimida mientras que el bit más bajo indica si la tecla está activa o no. Entonces, dado que la información que interesa está en el bit inferior, la aislamos con

GeyKeyState and 1

// Saludos

[dec]

Hola,


y no actualiza el statusbar cuando no esta activo:s,minimizado o en segundo plano.

Por eso digo que el OnIdle presenta el mismo "problema". Es por ello que me inclino por el timer.

No exactamente el mismo problema: la barra de estado se actualiza en cuanto el usuario pasa el ratón por la ventana (por ejemplo) sin ni siquiera activarla. Ya se ha ganado algo, por tanto.


¿De dónde sacaste la información roman?

Según eso, el bit más alto indica si la tecla está oprimida mientras que el bit más bajo indica si la tecla está activa o no. Entonces, dado que la información que interesa está en el bit inferior, la aislamos (...)

Pues gracias roman, por la información. Se tendrá en cuenta, pues.

[roman]

De hecho, creo que por ahí va la explicación del comportamiento. Como tú lo usas en el evento OnKeyUp, la tecla no está oprimida. No habiendo entonces nada en el bit superior, el resultado coincide con el and.

// Saludos

[dec]

Hola,

Bueno. Estupendo. No hubiera llegado ahí en años, y, aún así, no diré que he llegado, porque más bien me has llevado: veremos si sabría volver por mis pasos. Empero, aparte del evento "OnKeyUp" también llamo al procedimiento "ActualizarBarraEstado" en otros lugares programáticamente... claro que es posible que cuando lo haga (en varios lugares) no halla teclas pulsadas, ciertamente.

[dec]

Hola,

Seamos un poco realistas respecto del uso del "TTimer" o el evento "OnIdle". Creo que, como ya he reconocido, el evento "OnIdle" puede ser más que suficiente para lo que perseguimos si la aplicación es un editor de textos, por ejemplo. El dato "el bloqueo de mayúsculas está activado" (o no) tampoco es especialmente crítico. Me explico. Con el evento "OnIdle" si nuestro editor se minimiza, por ejemplo, y en el ínterin se cambia el estado de algunas de las teclas especiales que nos ocupan, en cuanto el usuario restaure la ventana del editor, la información del estado de dichas teclas se actualizará, casi sin que pueda uno darse cuenta.

Ahora. Si estuviéramos haciendo una aplicación que mostrara, precisamente, el estado de las teclas en cuestión, pero de forma exclusiva, esto es, una aplicación específicamente diseñada para tal efecto, entonces sí podría ser lo suyo utilizar un "TTimer" con pocos milisegundos de intervalo para que, independientemente del estado de nuestra aplicación (minimizada, en segundo plano, etc.) esta mostrase la información correctamente actualizada "a cada momento". Habréis visto este tipo de aplicaciones: consisten en una ventana, casi siempre "On Top" que se dedica en exclusiva a la tarea que digo.

Así, pues, como siempre, o casi siempre, todo dependerá de qué pretendamos hacer... no hay para esto, como para casi nada, una guía, mejor dicho, una regla, algo que casi nos oblige a hacerlo de un modo en concreto. Quizá por esto también es atractiva la programación: que permite llegar al mismo lugar, acaso, pero por diferentes caminos, no mejores ni peores, sencillamente, distintos.

[vtdeleon]

Saludos
Otra actualización: Soy estúpido a las veces. Acabo de probar lo que decías roman de utilizar el evento "OnIdle" y XEditor va de lujo así, mucho mejor, mucho más serio, como más pendiente de lo que le toca. He actualizado también el ejemplo adjunto de manera que también hace uso del evento susomentado. Gracias roman.X
Que extra~o,:s Cuando hiciste la ultima actualizacion, el archivo no tenia el evento OnIdle y ya lo citado anterior lo tenias posteado.
¿seguro que bajaste la actualización del ejemplo? ¿Te fijaste si se hace ya uso del evento "OnIdle"?Ahora si, Grax

[dec]

Hola,

Yo, de nuevo. Con mis escrúpulos. Y es que no dejo de pensar en la solución del "TTimer" que dice roman. ¿Qué tanto consume un "TTimer"? ¿Es una especie de fobia sin sentido la que, al menos en cuanto a mí se refiere, existe contra los "TTimer", que nos parece una locura utilizarlos, en cuanto a consumo de recursos se refiere?

Pero, si hemos quedado más arriba en que la mejor forma de mantener los datos que nos interesan en este hilo (recuerdo, el estado de ciertas teclas especiales, como Bloq. Mayús, etc.) es, precisamente, utilizar un "TTimer", ¿a qué no utilizarlo, pues, cuando es menester mostrar estos datos debidamente actualizados, sea el tipo de aplicación que sea?

¿Es esa supuesta fobia contra los "TTimer" algo que solo está en mi imaginación o sucede a otros programadores (vaya, incluyéndome en el grueso de ellos) lo mismo? En algún Hilo de estos Foros roman comentaba que las máquinas, los ordenadores, no son como nosotros... a ellas no les importa que un "TTimer" esté haciendo su trabajo incluso cada pocos milisegundos.

Uno se para a pensar que cada 23 milésimas de segundo se va a ejecutar determinada instrucción o instrucciones y piensa enseguida, ¡eso es demasiado! ¡Vamos a consumir muchos recursos! ¿Pero es realmente así? Y, cuando así fuera, si se demostrara cierto el consumo de tantos recursos, podríamos tener razones para negarnos a usar "TTimer", pero, ¿cómo, irrazonablemente, nos negamos, sin saber de veras qué tantos recursos se consumen?

Desde luego, es lo que me sucede a mí con los "TTimer". Fobia, contra ellos, pero fobia irracional, sino es ya que por ser fobia algo sea irracional al mismo tiempo. Y hago uso de "TTimer", pero, digamos, cuando la cosa está bajo control (eso me creo yo), por ejemplo, mientras se están buscando archivos en el disco duro: sabemos de antemano que la búsqueda terminará, o se cancelará, pero, en todo caso, el "TTimer" acabará deshabilitado en un momento u otro.

Pero, ¿un "TTimer" desde que se inicia el programa hasta que este se cierra? ¡Ni por pienso! Pienso yo... seguramente equivocado, porque no lo hago con razones suficientes, sino por la fobia que ya he dicho. Este es mi escrúpulo con respecto a lo que se trata en este Hilo. No sé si probar el método, pues, que roman refiere como el mejor para lograr los mejores resultados para lo que se pretende aquí.

Digo probarlo en el editor de textos que me traigo entre manos, y comprobar de una vez si es para tanto el consumo de recursos o no es para tanto como me parece a mí, vuelvo a decir, sin siquiera haberlo probado, solamente por no sé qué reparos ante los "TTimer". Veremos.

Disculpad el rollo, por favor, pero, como escrúpulo (http://buscon.rae.es/draeI/SrvltGUIBusUsual?LEMA=escr%C3%BApulo&TIPO_HTML=2&FORMATO=ampliado), no podía dejarlo pasar.

[roman]

No sé si probar el método, pues, que roman refiere como el mejor para lograr los mejores resultados para lo que se pretende aquí


Si dije que éste era el mejor método ha sido por error. Lo que yo recuerdo haber dicho es que éste era el método por el que yo me inclinaría y di razones de porqué me parece mejor. Pero yo no soy dueño de la verdad.

Sea o no el mejor método, hay algo en lo que quiero aclarar mi opinión.

Como bien dices,


El dato "el bloqueo de mayúsculas está activado" (o no) tampoco es especialmente crítico


De hecho, yo no pondría una información que normalmente ya se puede ver directamente en las luces del teclado, no le veo caso.

Otra cosa es el estado de la tecla INSERT. Si alguien oprime INSERT estando nuestra aplicación inactiva, no espero que ésta se actualice por el simple hecho de que a diferencia de CapsLock y NumLock, el estado de la tecla INSERT no es global, sino que es dependiente de la aplicación. Dicho de otra forma, pueden tenerse dos editores simultáneos, uno en modo de inserción y el otro en modo de sobrescritura.

Ahora bien, en mi opinión, no siendo crítico el poner el estado de CapsLock y NumLock, yo no lo pondría, pero si lo pongo, entonces intentaré que funcione a la perfección y no que casi funcione.

// Saludos

[dec]

Hola,


Si dije que éste era el mejor método ha sido por error. Lo que yo recuerdo haber dicho es que éste era el método por el que yo me inclinaría y di razones de porqué me parece mejor. Pero yo no soy dueño de la verdad.
No; no ha sido error tuyo, sino que, yo, puesto que tú lo decías, lo daba por el mejor. Pero, llevas razón roman, no estás en posesión de la verdad: nadie lo está. Empero, ciñéndonos a lo que tratamos es probable que estés más cerca de la mejor solución que yo, al menos.


De hecho, yo no pondría una información que normalmente ya se puede ver directamente en las luces del teclado, no le veo caso.
¿Entonces tenemos que pensar que todos los teclados cuentan con esas luces? ¿Que todos los que cuentan con ellas funcionan bien? No te confundas, me aproximo a tu opinión en esto. Respecto de lo de la tecla INSERT es algo en que quizá no hubiera caido, pero estoy de acuerdo contigo, obviamente.


Ahora bien, en mi opinión, no siendo crítico el poner el estado de CapsLock y NumLock, yo no lo pondría, pero si lo pongo, entonces intentaré que funcione a la perfección y no que casi funcione.

Ejem... ¿Entonces tienes algún método que elegirías para considerar que todo está funcionando a la perfección? ¿En este caso se trata de un "TTimer" cada pocos milisegundos? ¿Me equivoco? ;)

[roman]

¿Entonces tenemos que pensar que todos los teclados cuentan con esas lueces? ¿Que todos los que cuentan con ellas funcionan bien?


Hasta ahora no he visto nunca un teclado que no disponga de esas luces, pero en todo caso, no creo que mi aplicación deba solventar la carencia o mal funcionamiento del hardware.


Ejem... ¿Entonces tienes algún método que elegirías para considerar que todo está funcionando a la perfección? ¿En este caso se trata de un "TTimer" cada pocos milisegundos? ;)

No importa que método use; lo que quiero decir con "perfección", es que, en caso de querer mostrar el estado de CapsLock y NumLock en mi aplicación, entonces veré la forma de que tal estado se refleje en todo momento.

Además del Timer se me ocurre un thread aparte en donde hacer la actualización o bien usar ambos, el Timer y el OnIdle, habilitando el timer cuando la aplicación se desactive e inhabilitándolo cuando se active.

// Saludos

[roman]

Por cierto, lo que sí he visto son teclados sin la tecla ScrollLock, pero en realidad jamás he sabido para qué diantres sirve. Ni siquiera en los tiempos del DOS.

// Saludos

[dec]

Hola,


Por cierto, lo que sí he visto son teclados sin la tecla ScrollLock, pero en realidad jamás he sabido para qué diantres sirve. Ni siquiera en los tiempos del DOS.

Bueno... también yo lo desconocía, y, a lo que se lee (http://www.computerhope.com/jargon/s/scrolock.htm), no suele hacerse un uso correcto de esta tecla: en el caso del editor que me traigo entre manos desde luego que no.


Hasta ahora no he visto nunca un teclado que no disponga de esas luces, pero en todo caso, no creo que mi aplicación deba solventar la carencia o mal funcionamiento del hardware.

Sobre eso habría que hablar, pero, estoy de nuevo de acuerdo contigo roman.


Además del Timer se me ocurre un thread aparte en donde hacer la actualización o bien usar ambos, el Timer y el OnIdle, habilitando el timer cuando la aplicación se desactive e inhabilitándolo cuando se active.

Desde luego, me parece algo demasiado complicado, para lo que se trata de conseguir. He pensado que Delphi, por ejemplo, el editor, me refiero, no muestra el estado de las teclas que nos ocupan.

Así pues yo estoy en el editor haciendo una cosa mal y otra tal vez con poco sentido: la primera y mal hecha es mostrar el estado de la tecla "Scroll Lock", siendo así que en modo alguno el programa hace uso del estado de dicha tecla; la segunda, que tal vez esté demás, es indicar el estado de las teclas "Bloq. Núm" y "Bloq. Mayús"... no creo que esto sea una carencia del editor de Delphi: he convivido con él cierto tiempo y no he echado en falta esa característica.

Total, que me he convencido, en todo o en parte gracias a ti roman, y el editor en cuestión va a dejar de mostrar el estado de dichas teclas. Creo que será lo mejor, por eso lo haré así.

[roman]

He aquí un bonito uso- absolutamente inútil por otro lado -de la tecla ScrollLock:



if GetKeyState(VK_SCROLL) and 1 = 1 then
Memo1.ScrollBars := ssVertical
else
Memo1.ScrollBars := ssNone;


:D

[vtdeleon]

Saludos
Hasta ahora no he visto nunca un teclado que no disponga de esas luces,.. Tengo uno de esos teclados(A4 Tech Keywords Office), fastidio, ya que no se el estado de las teclas:mad:, a pesar de que tiene la posicion de las teclas comodas para la muñeca de la mano:rolleyes:

[roman]

Pues es increible. Bueno, te creo ya que lo dices pero me parece un absurdo. En algo tan simple como escribir una contraseña, ¿cómo se supone que sabe uno si están activadas las mayúsculas o no? :confused:

Claro que no será la primera vez que algún recién egresado de diseño industrial salga con una "brillante idea". Por mi parte el peor teclado que he tenido es uno donde las teclas Home, End, PgDn y PgUp estaban montadas sobre las mismas teclas que las teclas de dirección así que había que usar la tecla modificadora Fn para usar unas u otras. :mad:

Me consuela pesar que estos diseñadores serán condenados en el infierno de los informáticos a escribir día tras día hasta el fin de los tiempos en un teclado así. :D

// Saludos

[vtdeleon]

Saludos

¿cómo se supone que sabe uno si están activadas las mayúsculas o no?Solo en WinXp me doy cuenta, ya que cuando el edit consigue el foco sale el Hint, avisandote del estado del Caps

[roman]

Pues ahora entiendo la ira que muestra tu avatar :D

Pero en serio, puedes conseguir teclados baratos y con lucecitas :D

// Saludos

[roman]

Pero fíjate que aún en este caso, no modificaría mi aplicación para ello ya que de por sí es un problema que se presentará en cualquier aplicación.

Si yo estuviera en tus zapatos quizá optaría por una solución muy sencilla y global.

Te armas una aplicación sin formularios y sin botón en la barra de tareas. La aplicación simplemente colocaría un icono en la bandeja del reloj y usaría un Timer para poner una imagen en el icono que refleje el estado de las teclas.

EDITO

Una vez que termines la aplicación se la vendes a todos los que hayan comprado ese teclado. :)

// Saludos

[vtdeleon]

Jeje
Pero en serio, puedes conseguir teclados baratos y con lucecitas :D Ya soluciones eso, tengo mi lapto. Ahora es otro problema, el NumLock, parecido a tu caso Por mi parte el peor teclado que he tenido es uno donde las teclas Home, End, PgDn y PgUp estaban montadas sobre las mismas teclas que las teclas de dirección así que había que usar la tecla modificadora Fn para usar unas u otras. :mad: pero en medio de letras:mad:. Para conseguir "ñ" me enojo hasta la madre (http://www.clubdelphi.com/foros/showthread.php?t=24181), prefiero poner "~", no me queda mas que seguir aguantando

[vtdeleon]

Una vez que termines la aplicación se la vendes a todos los que hayan comprado ese teclado. Me haré rico. He visto montones de esos teclados en esta ciudad.