In SDL2 the documentation suggests that the number used to open the joystick (between 0 and SDL_NumJoysticks()) can be different than the SDL_JoystickID which; used to reference the stick in events. When are these numbers different?
Code should assume the numbers are always different (even if they happen to be the same sometimes). For example, when you get a SDL_ControllerAxisEvent, the which field should match the value of SDL_JoystickInstanceID() for one of your open joystick handles. You can use SDL_JoystickFromInstanceID() to get the joystick handle from the which value.
Related
I am developing a tool that displays a status about various hardware components on a system we use at work. Currently, we have 16 touch screen monitors (all by 3M) plugged in to a Windows 10 box. I need to verify that any given monitor has an associated touch screen recognized by windows. This is to assess the system for any hardware malfunctions i.e. bad cable, bad USB port, bad Monitor, etc. We see this more than we would like to admit, usually where a monitor's display will be working fine but the USB controller on either end drops out and needs to be reset by unplugging/plugging back in
Unfortunately my code posting will be limited due to work constraints.
I can enumerate all of the monitors plugged in to the system via winapi's EnumDisplayDevices and EnumerateDisplayMonitors. I am able to build a list of all the HID touch screen devices using HIDApi.
From here I have no direction on where to go to link these two things together, if it is even possible. My first thought was the HID device information should have some sort of identifier shared by the results of calling the EnumDisplayDevices and EnumerateDisplayMonitors, but I have not found this to be the case. Another possibility would be to compare the coordinates/size of a monitor to a region that one of the touch controllers is responsible for. Again, not sure if that is possible.
In short, is there a way to associate a Touch device with it's corresponding monitor via c++?
I think you were just lucky that this driver suffix matched your monitor configuration. In my Windows 10 multi-monitor setup I get wrong displays when I look them up with this number in the driver entry as you described.
A reliable way for associating a HID device with a display seems to be:
Call GetRawInputDeviceList() to obtain the HID devices
Call GetRawInputDeviceInfo() with RIDI_DEVICEINFO to determine Usage and UsagePage
Call GetRawInputDeviceInfo() with RIDI_DEVICENAME to get a device string in the form \\\\?\\HID#VID_0EEF&PID_7200&Col01#6&152cc7f9&1&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
Query the registry for the mapping table at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Wisp\Pen\Digimon and look up the display device name. In my case the HID names are all prefixed with 20- there but the remaining part seems to match the name queried by GetRawInputDeviceInfo() exactly. As a fallback method in case there is no match, I also parse the middle part as Clay Brooks described in his answer.
Call EnumDisplayDevices() with a null pointer for lpDevice and 0 for dwFlags in a loop until the function returns zero.
Within each loop iteration, call EnumDisplayDevices() again with the current device as lpDevice and EDD_GET_DEVICE_INTERFACE_NAME for dwFlags and observe that it returns a DeviceID in the form \\\\?\\DISPLAY#ELO2243#5&607b301&0&UID24833#{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}
Loop until a HID <-> display match is found and take the DeviceName returned by the "outer" EnumDisplayDevices() call which should be something like \\.\DISPLAY3
After the suggestions in the comments and looking deeper into the registry, I've found a way to link Touch controllers to a monitor.
Using HIDApi, you can poll the system and find a list of all the Touch Controllers you need to monitor. I filtered by the VID of the monitors we are using. A sample return value for the path looks something like this:
"\\?\hid#vid_0596&pid_0520&col02#8&33d9e616&0&0001#{4d1e55b2-f16f-11cf-88cb-001111000030}"
The bold part can be used to link to the entries in HKLM/Software/Microsoft/Wisp/Pen/Digimon. An example entry is this:
"\\?\HID#VID_0596&PID_0520&Col03#8&33d9e616&0&0002#{4d1e55b2-f16f-11cf-88cb-001111000030}" "\\?\DISPLAY#MSY1C2B#7&1083071f&0&UID524#{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}"
The first bold matches the data found through HIDApi and the second set of bolding, the monitor name and a UID, is listed in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY. Under here you can use the combination of monitor name and UID to find the Driver entry. Below is a sample driver entry:
{4d36e96e-e325-11ce-bfc1-08002be10318}\0010
The last bold number can then be used to match up with a DeviceID returned from EnumDisplayDevices(). Below is a sample DeviceID:
"MONITOR\MSY1C2B\{4d36e96e-e325-11ce-bfc1-08002be10318}\0010".
Then you can use this bolded section to match up to names of monitors returned from EnumDisplayMonitors().
Environment:
PDCurses latest version
Windows 10
Visual Studio 2015 Update 2
Problem
PDCurses provides a function getmaxxy to get the maximum x and y coordinates of the screen. This returns correct values on startup, but if I resize the window with the mouse and then call getmaxxy again, I get back the same values.
Is this a bug/limitation in pdcurses? Is there a windows specific way to get this information instead?
I have also tried this windows specific solution and it too, always returns the startup values: Getting terminal size in c for windows?
Reading the source,
the _maxx and _maxy members of WINDOW are set only when creating a window (including duplicating a window).
stdscr is a window
If you have resized the screen, then you should tell PDCurses about the new size, using resize_term (a function adapted from ncurses), e.g.,
resize_term(new_lines, new_cols);
and that recreates the standard windows such as stdscr.
For what it's worth, PDCurses provides these functions for compatibility with ncurses:
curses_version
is_termresized (should have been is_term_resized)
resize_term
wresize
Just check for a KEY_RESIZE, and if it occurs, call resize_term(0, 0). You can see several examples of this in the demos (in testcurs, rain and worm). is_termresized() can be used if you're not checking keyboard input.
resize_term() is effectively two different functions -- with zeroes as the parameters, it responds to user-initiated resizing; with non-zeroes, it attempts to actually resize the window to the given size. Typically only one or the other capability (or neither) is available on a given platform. SDL allows both.
Lets say I have printed out a value to my console application using std::cout<< and have not ended the line, then later on I wanted to add data to the same line and input it into my programme through getline(cin, MyInput), but I want to make use of the entire line rather than just the values in-putted through the keyboard.
consider the value printed out on the screen is 5 and then * 6 is entered through the keyboard, then my programme should multiply 5 * 6! (this is not the purpose of my programme im just trying to get the idea across)
I have tried using a variable that holds the value printed out onto the console application and then I reused this variable but this is not the ideal solution, what I am looking for is a method to consider everything printed on one line (whether its from cin or cout) as one!
What you are trying to do sounds like a bad design. If there's a background process started by the user that spews garbage to the console, do you really want to take that in as part of your input?
What I think you are trying to do is to have some state stored and retrieved as part of the input/output operations.
The clean way to do this is to have a dedicated component/library that does input/output for you. That way when you output something the library can store it (or discard it if it's not intended for storage, for example debug output). When you want to read something the same library can provide back the data stored and merge it with the data it gets from cin.
I'll try to keep this as short as possible.
I have an app that has worked for years with a single mouse input. I am looking to incorporate the ability for my users to use other forms of input, such as interactive projectors, touch devices, or pretty much anything that provides WM_INPUT messages when you register for them.
The general idea I had was I would have a list of Vendor IDs and/or Product IDs that I would handle with Raw Input (which provides VID/PID, device handle and other information) for each message (WM_INPUT) received. Any devices that are not handled in the Raw Input code would be handled in the Mouse Input code (WM_MOUSEMOVE, WM_LBUTTONDOWN, WM_RBUTTONDOWN, etc).
Ideally, I would be able to leave all of my Mouse Input code as is, or close to it. This way, if a user plugs in two mice, or a mouse and an unsupported pointing device (meaning my Raw Input code doesn't handle it based on VID/PID) the devices would both use the same system cursor. Any device that is known by my Raw Input code would be given separate cursors that exist only within my app.
The problem is simple: Mouse Input does not provide any information about the source of the message (such as WM_MOUSEMOVE, etc). Knowing that the message originated from touch helps (I have this implemented) but is definitely not enough. I need some kind of unique identifier. If I could know the source of the Mouse Input, I could only handle Mouse Input from devices that aren't on my list of known devices, and I could only handle Raw Input that are on my list of known devices.
Unfortunately, I cannot seem to find a way to achieve this.
Any ideas?
Thanks for your time sorry for the lengthy post.
TL;DR - Can you identify the source of Mouse Input (not Raw Input) in Windows? Determining whether or not the source is touch is not enough information, I need some kind of unique identifier.
Mouse Input - http://msdn.microsoft.com/en-us/library/windows/desktop/ff468877(v=vs.85).aspx
Raw Input - http://msdn.microsoft.com/en-us/library/windows/desktop/ms645536(v=vs.85).aspx
I don't know of any API for getting some sort of device id after the fact.
You could use the fact that WM_INPUT messages come before all other input messages, and when you handle WM_INPUT you could use GetRawInputDeviceInfo and a hash of the name returned by RIDI_DEVICENAME to use as a unique id. Or, you might be able to use the hDevice member of the RAWINPUTHEADER structure.
edit2: The answer to this question is "Not possible", you can't do it. Don't bother trying, but if you do and I'm wrong please explain. The fact of the matter is you can't rely on Windows to provide messages in any particular order consistently, which is what I was attempting to do. This bit me big time. Either use raw input (WM_INPUT) or use mouse messages (wm_mouse) don't try to combine the two somehow.
I never really got the answer I wanted, but I got something that works so I thought it was worth sharing.
I am working on a huge assumption, as I can't find any documentation from Windows to support this assumption (and probably wouldn't really even trust it if I found documentation from windows). To my understanding, when a mouse event is generated at the lowest level it comes through the system as a raw input message first (WM_INPUT). After the WM_INPUT message is posted, the OS gets the message and applies the ballistics and whatever else it does before a WM_*MOUSE* message is posted. The huge assumption is that this process is serial in that it is always 1 WM_INPUT message followed by 1 WM_*MOUSE* message in the queue.
With this assumption I am working with the following:
When an input message is received, store all relevant information about the source device as the "current input information"
When a mouse message is received, process it using the "current input information" as the source of the mouse message
This allows me to use n inputs in my application independently.
I'd also like to add that per Brandon's suggestion I am using the hDevice member of the RAWINPUTHEADER structure to uniquely identify each input. Since a unique device can have multiple inputs, I have yet to come up with a good way of uniquely identifying each device. VID/PID doesn't work because you can have 2 of the exact same device with multiple inputs each plugged in. I'm still working on this, see Windows HID Device Name Format
Please let me know if anyone would like me to elaborate!
edit: not marking this as the answer since I believe the correct answer is "Not possible"
I have some text to write to the Windows console that I need to know the real width of in columns. wcswidth_l seems to be the best option on platforms that have it (though mbswidth_l() would be better since I have no desire to use wchar_t, but for some reason it doesn't exist). But in addition to other platforms, I need something that works on Windows. Although it's unlikely that there's a portable solution, I don't know of any solution at all on Windows. I think the console has an API for getting cursor position and such, so I could write the text out and check the change in position. That would be accurate I guess, but writing out extra output isn't acceptable at all.
How does one go about getting the column width of a string or character on Windows?
Edit:
wcswidth_l returns the number of console columns used to display a string. Some characters take up one column and others, e.g. japanese characters, take up two.
As an example the 'column width' of "a あ" is four. 'a' is one, ' ' is one, and 'あ' is two. (Assuming the console is set up to actually display non-ascii characters that is). Also it'd be nice if the API supports strings using codepage 65001 (UTF-8).
First of all, the Windows Console API is located here.
Secondly, is the function you're looking for GetConsoleFontSize?
I'll try to quickly type an example in a second.
EDIT: Here you go. Forgive me if it there's a small error. I actually found it was even easier. GetCurrentConsoleFont fills in a COORD structure on the way to you getting the index to pass to GetConsoleFontSize, so step saved :)
#define _WIN32_WINNT 0x0501 //XP, 0x0601=windows 7
#include <windows.h>
int main()
{
HANDLE hStdOutput = GetStdHandle (STD_OUTPUT_HANDLE);
CONSOLE_FONT_INFO cfi;
GetCurrentConsoleFont (hStdOutput, FALSE, &cfi);
//cfi.dwFontSize.X == x size
//cfi.dwFontSize.Y == y size
}
EDIT:
If you don't mind invisible output, you can use CreateConsoleScreenBuffer to pretty much have an invisible console window at your command while leaving yours unaffected. GetConsoleScreenBufferInfoEx will tell you the cursor position, at which point you can use WriteConsole to write to your buffer (invisibly), and check the cursor location again versus the number of characters actually written. Note that checking the cursor location beforehand would not require clearing the screen to use this method.
If you cannot afford to do extra output, visible or invisible, I'm not sure there really is a possibility.
Portable approach
Since width of characters depends more on characters themselves rather than the system on which they are displayed (ok, there might be excepetions, but they should be rather rare), one can use separate function to do that (on Windows too). This requires Unicode characters as it makes it much easier to analyze width of strings, but one for sure can write a wrapper to convert between encodings.
Available implementation
Here is suitable and portable implementation, which one can plug in into his application and fallback to use it on Windows.