Inconsitency in number handling between Linux and Windows (or lacks of documentation to this behavior)

[rgiot]

Describe the bug Windows does not seem to be able to generate key events for numbers (but also for other chars).

To Reproduce This minimal example illustrates the issue.

#!/usr/bin/env rust-script

//! ```cargo
//! [dependencies]
//! enigo = "0.2.1"
//! ```

use std::time::Duration;

use enigo::{Enigo, Key, Keyboard, Settings};


fn main() {
	std::thread::sleep(Duration::from_millis(1000));
    let mut enigo = Enigo::new(&Settings::default()).unwrap();
    enigo.key(Key::Unicode('#'), enigo::Direction::Click).unwrap();
    enigo.key(Key::Unicode('0'), enigo::Direction::Click).unwrap();
    enigo.key(Key::Return, enigo::Direction::Click).unwrap();
}

Expected behavior When launched with Linux, the following output is obtained:

$ rust-script test_enigo.rs 
#0

Obtained behavior When launched with Windows, the following output is obtained:

> rust-script.exe .\test_enigo.rs
thread 'main' panicked at XXX\test_enigo.rs:16:59:
called `Result::unwrap()` on an `Err` value: Mapping("Could not translate the character to the corresponding virtual-key code and shift state for the current keyboard")
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

The problem comes at least from enigo.key(Key::Unicode('0'), enigo::Direction::Click).unwrap();, but in this example # is problematic too (hence the line 16 reported).

Environment (please complete the following information):

• OS: Windows
• Rust 1.81.0-nightly
• Library Version 0.2.1

Additional context

I do not understand why there is this faulty behavior on Windows. Either there is a bug in the library, either this is a known limitation. In that case, what are the workarounds ?