You can never write a correct low-level keyboard hook that translates virtual keys to typing keys. The keyboard state and the active keyboard layout are properties of the process that owns the foreground window. Never of the process that implements the hook.

In particular the keyboard state will be wrong, you don't know if the logical state of the keyboard for the process has the shift, alt, control and Windows key active. That state is recorded when the program receives a keyboard event. Particular to a keyboard layout for languages that use diacritics are the state of the dead keys, the ones you type to get the next typed letter to have an accent. This keyboard state is a per-process state and cannot be retrieved from another process. It is only discoverable within the process itself, GetKeyboardState() function. Much the same for the active keyboard layout, GetKeyboardLayout() function. The language bar allows processes to use different layouts.

It can only ever work 100% correctly when you use a WH_KEYBOARD hook. It requires a DLL that can be injected into other processes. The 3rd argument of SetWindowsHookEx(). Which ensures that GetKeyboardState and GetKeyboardLayout return accurate information. You cannot write such a DLL in VB.NET, the process you inject won't have the CLR loaded to execute managed code. A language like C, C++ or Delphi is required, languages that have very modest runtime support requirements. This is usually where the project peters out. Not just because of the runtime injection problem, debugging such code and dealing with the bitness of a process on a 64-bit operating system as well as UAC are major headaches.

You can limp along somewhat by using GetAsyncKeyState() to get the state of the modifier keys. There is no solution for dead keys other than an injected DLL. This is not a helpful answer, it merely explains why you can never make it work completely reliably in vb.net.

The mapping of Keys.Oemtilde to a typing key is the job of the keyboard layout. Different keyboards produce different letters for that key. The underlying winapi function is ToUnicodeEx(). Note how it requires the keyboard state and layout as I described.

A global WH_KEYBOARD hook however executes in teh context of the app. that is recieving the keyboard message so your code has to be injected into every running process. This is NOT a good idea IMHO.

¿Elektro, puedes subir un video donde se muestre algún aumento exagerado (algunas decenas de Mb) o decirnos hasta cuánto ha llegado este aumento?

(No es necesario que hagas doble post para comentar el mismo problema...)


Si no tienes un AntiVirus instálate el Avira o el NOD32, y pásale un "escaneo profundo" a tu PC para desinfectar ese "Download.exe" en caso de que lo hayas ejecutado.

Después de eso renombra o elimina (como prefieras) la carpeta de tu perfil de usuario de Firefox para que los cambios sospechosos que se hayan hecho en tu perfil no sucedan más, o en su defecto haz una reinstalación LIMPIA de Firefox (Primero desinstalas Firefox junto a los perfiles guardados y luego instalas la última versión de Firefox 22.0, para que no siga usando la configuración de tu perfil de usuario).

PD: Tu perfil lo puedes encontrar aquí:
Código:

C:\Users\Administrador\AppData\Roaming\Mozilla\Firefox\Profiles


Saludos...

Y si pruebas ejecutando el EXE en release SIN el depurador de visual studio?

¿Te ocurre únicamente en modo de de puración?

el recuva me pierde archivos...

Usa el RECUVA

No entiendo muy bien por qué te surge la duda.

Por qué no intentas haciendo una pequeña prueba, en donde tengas bloque que estime el tiempo de ejecución del programa

Pero hazlo hasta el extremo a ver si tu pc se cuelga o algo, si no es asi es porque como dice por ahi "el GC lo deja crecer pero cuando es necesario lo borra"

Probé lo que comentas y si, pasa eso, incluso cambiando opciones de compilación

There are messages that trigger for handling mouse movement, etc, which get processed by the form.

It will. Eventually, you'll see your memory settle down. In C# and VB.Net, the garbage collector doesn't immediately clean up memory (by design), but lets it grow, and will clean up as needed. In general, you'll tend to see .NET applications grow in their memory usage, then drop dramatically, then grow again, then drop, etc. If you have a lot of memory in your system, the "drops" happen infrequently, since a garbage collection is expensive, and there's absolutely no disadvantage to using memory that's not needed elsewhere.

no, al menos yo no puedo.