On my laptop (MSI GE63VR 7RE) GLFW passes GLFW_KEY_UNKNOWN to the key callback function when pressing the space key (and some other keys).
There is a scancode for almost all keys, but these are supposed to be machine specific and there is no convenient way to map them to the correct key names.
Why does GLFW not recognise my space key as GLFW_KEY_SPACE and what would be the best way to work around this?
Im on arch linux with wayland and am using the glfw-wayland 3.2.1-1 package
Yep, the problem was wayland. Switched back to Xorg and it works fine.
Related
I am writing an C++ Application and have to read if an arrow key is pressed or not.
I only found some function that are only working on Windows.
You have such problem because you just ask the wrong question. If you application is a command line tool and is accessible from a terminal, than it's just impossible to know which keys are pressed at the moment because the terminal can be far away from the machine where your application runs and which is more important, there is no reason for terminal to send you the arrow key presses because terminal can use them for text navigation.
So you may search how to make the terminal to send you key presses. Not every terminal will support it, but, I think, most of modern terminals in modern OS do.
If you has a gui application that is for running locally and assuming that you control it from the keyboard that is plugged in. Than you should search for the documentation for your gui toolkit. (Qt, wxWidgets, raw xorg, windows API, etc.)
So there are just no native C++ solution for this problem because you question just has no sense in many situations.
So you can use some console library like ncurses or gui toolkit like Qt or search for a native solution in your particular situation, but don't expect this last way will work without any additional code on other machines.
Or just search for other libraries that can allow you to do it.
As you say you only found material for Windows, I assume you are looking for a Linux-Unix way. Old dinosaurs like me remember the time when we only had true consoles (only a keyboard and a 80x25 display). And in these early times existed low-level libraries to interpret keypad transmitted keys and position cursor on screen on almost any terminal, and higher level ones to use the screen as a (text only) GUI.
You should look for curses or ncurses for high level libraries, and terminfo for the low-level capabilities.
I have coded up a low level keyboard hook using SetWindowsHookEX() on Windows CE 4.2 and it seems to work just fine. I am able to see key events using the keyboard and a barcode scanner in notepad and other applications as desired, but I do not see the barcode scanner events in the one application that I want to collect the keys in. I still see events from the keyboard, however, so I know that the keyboard hook is still working and in the hook chain. I have even tried inserting my hook in the chain every millisecond just to see if it would make a difference, but no dice. If I flip back to notepad, it's back to working the way I want it.
I'm not sure what the other application is doing to gain control of the scanner when that application is active that prevents it from acting like a keyboard any more. Any thoughts on this would be greatly appreciated. I've done a bunch of searches without any success. I looked into trying to use RAWINPUT, but it doesn't seem to be supported in Windows CE 4.2 from what I can tell as I don't see the user32.dll in the SDK.
There are two ways to get barcode data on most WEC devices.
The keyboard wedge (where data comes in as as keyboard events)
An OEM specific barcode reader API
If this other app your looking at uses option #2 then there is no keyboard data to retrieve, so it makes sense you wouldn't see any. That said, you might read this article to see if it offers any tips for your keyboard hook.
Functions exported by user32.dll in big Windows are generally found in coredll.dll in WEC/WEH.
-PaulH
This is the context: I am running Debian GNU/Linux and I switch reguarly with desktop environments ("DE" for the next).
My question is simple : I want to know which operation, syscalls or even functions used when I press the keyboard key "Print Screen".
Does the way changes with DE? I.e. do Mate, Gnome, KDE, LXDE or Xfce (etc) used a particular call of their own code or is there a generic syscall?
I think the answer (if any) is not Debian relative but more X or Wayland, is not it?
Thank you in advance for you advices and answers :)
PS: I precise that I read a good part of X lib source code, but did not find something useful.
Print screen itself is definitely not a syscall, but the kernel daemon which gets key presses definitely causes a routine to execute that uses what you would call a "syscall." I put that in quotes, because printscreen probably causes a program to run which is already in kernel space, which means there won't be any system calls to the kernel since you're already there (unless the window manager actually runs at user space, which isn't true for Mac OSX or windows, and I'm assuming for linux as well).
How does it work? It probably works by copying the current display from the screen buffer (region of ram which is DMA'd to your graphics card), and then transforming the pixel representation into a bit map.
The basic principle can be found in the xwd tool.
The code isn't that bad to read. In the simple scenario, it used XGetImage, but if the screen has multiple visual regions, it gets more complex, but the fundamental principle is to use XGetPixel to get screen pixels and XPutPixel to store in the temporary image.
What happens when you press PrtScrn is the same thing, except it may be some other application that starts. Exactly what application depends on what the graphics package is in the distribution (Gnome, KDE, Unity, etc). But internally, they will do something very similar.
Edit:
As Peter points out, if the windowing system is "compositing" (that is, each window draws its own content off-screen, and the graphics hardware combines the output via composition), then the screen capture is required to ask the composition system to render the output off-screen, and then copy that.
I am just wondering is there a way to get
the value of a textfield from another
application?
Windows OS
For example in window a textbox2 has a value of 1.
How would i get the value of textbox2 from another application then?
Read up on IPC. You should be able to find a solution on that webpage that suits your needs.
In general, if you want to send information between to applications there are a number of ways to do it. Depends entirely on you circumstances. Why don't you try a search here on SO? There are many related questions:
Passing information between two seperate programs
Elaborate your question or search for yourself.
You can use Windows APIs to get the handle of the target window and get its text. Look for
FindWindowEx or EnumWindows Win32 APIs for this purpose.
Remember that this solution only works for Windows you can not port it to Linux!
If you are looking for a generalized solution that will work between two applications across different platforms and machines (i.e. Window 1 is on a Windows PC, Window 2 is on a Linux PC), check out libQxt and it's IPC classes. Specifically, you might want to look at QxtRPCPeer.
How can I completely disable the keyboard using c++ in windows? And by completely disable I mean so even Ctrl+Alt+Delete doesn't work. I did consider using a keyboard driver but I think you need to restart the computer after it is installed, but since I only need to disable it for a couple minutes that wouldn't really work.
This is not really possible.
WinLogon is designed as the one process that intercepts the Ctrl+Alt+Del key press, even when all other things hang or die.
This is the failsafe against malicious sessions, etc. So there is no obvious workaround.
Maybe a keyboard filter driver would make your request possible, but that is a real kernel-driver.
You can't disable Ctrl-Alt-Delete without removing the keyboard or replacing the keyboard driver, it generates a kernel level notification.
You could use BlockInput function. But it doesn't block CTRL + ALT + DEL.
You could install a keyboard hook and filter out the messages, but you might need to have your application as the top most window. Even then Ctrl+Alt+Del would not get filtered out.
Here's SetWindowsHookEx on MSDN
Example of Hooking the Keyboard
Ok, here goes several random suggestions. I don't have a definitite answer, but here's where I would start:
1) SetupDiRemoveDevice is probably the API you want to call. Although to call it, you'll need to make a lot of other device enumeration calls. Enumerate your HID and USB devices and find the keyboard. Start by looking for the VID/PID of the actual device for starters.
2) Delete the drivers kdbclass.sys and kbdhid.sys. You'll be fighting Windows system file to do this. I have no idea if this will work, but sounds interesting and simple.
3) Write a USB filter driver. Your driver will need to know (or be passed) the vid/pid of the device to filter on, but it might work.