There is osgGA::GUIEventAdapter in OpenSceneGraph that could detect mouse events. However, I want the program to detect two mice on the same computer and the program can only treat two mice as one. I know there is a Windows MultiPoint Mouse SDK, but I think it is used in WPF with C#, not sure if it could be used in C++
Also, there is a GlovePie, but it is not open source and not sure how to use that in vs2010.
VRPN may be a good choice, but do not know exactly how to implement two mice. Get the dll files of two mice and extract functions by vrpn?
Take a look at "Raw Input" (http://msdn.microsoft.com/en-us/library/windows/desktop/ms645543(v=vs.85).aspx)
From that page:
An application can distinguish the source of the input even if it is from the same type of device. For example, two mouse devices.
Related
I'm writing a code, and I'd like to make it in two variants - with text-based interface (TUI) implemented with ncurses, and with GUI implemented with Qt5. So, passing an argument in the command-line, I can choose which version to run - with GUI or TUI (e.g., just like with YaST in openSUSE). The rest of the code, including inputs from the keyboard, should be independent of which interface (TUI or GUI) is chosen. As I see it, the optimal way to implement such a program is to use distinct classes for input, for user interface, etc. So, in whatever version I run the code, the class handling the input should be the same, and it passes the data to the interface class, which might be TUI or GUI, depending on how the application was launched. The problem is that for ncurses it seems impossible to detach input from the output. Basically, what I want is to still be able to use ncurses output (windows, panels, etc.), but to perform input with some other library. Anyone knows how to solve that? Also, what input C/C++ libraries can I use for reading keyboard event in whatever mode (terminal or GUI)?
You do not have to use ncurses' input-functions (such as wgetch) when using ncurses for output.
A few programs do this (Midnight Commander, vi-like-Emacs) because they use inputs that largely are not resolved to special keys using ncurses, such as
the escape character by itself (vi-like-Emacs), or
the mouse-code in Midnight Commmander (which uses select for monitoring multiple inputs).
Managing different output streams actually can be more difficult, since those use information about the appearance of your program on the computer screen. Inputs usually do not occupy more than a line or so of the screen.
In vi-like-Emacs, the program uses a terminal-driver which knows how to work with a specific type of device (terminal emulator, X windows, Win32 GUI), and the program is compiled and linked with that driver. It would be nice to be able to switch between drivers at runtime, but nuances of mouse-handling are harder to factor out than keyboard input and screen updates.
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 am running Arch Linux on a Raspberry and need to get the positioning data for 4 USB mice from a C++ application, as in for each individual mouse I need to know how many pixels it has moved whenever it moved. I do not have x server on my system and would prefer to leave it that way unless necessary because this is for an embedded project that does not require a GUI and I would prefer not waste space or overhead on x server.
The most useful thing I have found is this link https://www.kernel.org/doc/Documentation/input/input.txt but I cannot really figure out how to make it work for my purpose. As can obviously be determined I am NOT experienced in Linux development do don't be to hard on me please.
You open e.g. /dev/input/mouse0 for reading (using open), then read the structure defined in the document you linked (at the bottom of the document), it also says which header file to include.
I'm guessing you will get an event of type EV_REL for mouse-movement, with a code of REL_X or REL_Y for the direction of the movement, and the value is the number of units the mouse moved. Compare the timestamp to the timestamp of the previous event to see how fast it moves.
Is there some basic way to draw something in C++?
I know there are lot of engines, libraries etc. But these libraries have to use some most basic drawing function or whatever it is. I mean normally without any non-standart c++ libraries you are only able to make console applications. But the new libraries that can draw something, or atleast show something different than standard command line, have to use some basic function that allows to make something different without commandline.
I've heard about WIN32 API (I'm not targeting just Windows platform,vbut I'm using windows, still have Ubuntu(Wubi)). I just can't belive that the only way is to use WIN32 API.
So I guess my questions are as follows:
Are all GUI(or non-console) libraries using WIN32 API as basic?
Are linux developers required use some linux API for GUI?
(Sorry for my English, it's not my native language)
The operating system (on a modern computer) is in charge of the screen so you have to use it's functions to draw on the screen.
There are a whole range of libraries from very high level ones, where displaying a video is a single line of code, to low level ones where you can determine the details of every pixel.
As well as drawing on the screen a GUI library, or toolkit, is also responsible for handling keyboard and mouse, for dealing with other windows going over your window and for drawing all the standard controls such as file open boxes etc - that's why it's a bit complex.
See minimal cross-platform gui lib? fro some examples
The scenario is such: there's a program which loads my .dll/.so and calls a function from within it, possibly multiple times, each time expecting a different pointer to state. It uses the different states later in other calls into the dll. (It's a game AI, if you need context; each state is a AI player.)
What I want is a cross-platform way of creating a canvas window for each of those states (for visualization, debugging, etc.) I tried wx, but put it on hold, since it didn't appear to be easy at all. Are there any neat and small libraries that could do that or should I just go with WinAPI/X...?
Edit: Assume I cannot modify the host program.
Qt is simpler to set up and drive than Wx, in my experience. It's very cross platform too.
If you want to render some graphics from inside your DLL function without passing in any pointers to QImage or QWidget type things, probably the thing to do is use OpenGL. Your DLL should just render to the current OpenGL context, which is global state and can just be setup outside the DLL (maybe using QGLWidget).
Update: Ah, I just noticed your edit re not being able to modify the host code. This is a problem: any windows you create really need to be plugged into the host apps' event loop to work properly (e.g receive WM_PAINT when exposed/resized). It's certainly possible in win32 for any old code (e.g your library) to just CreateWindow and draw its contents with GDI whenever it gets the chance, but the general window behaviour may be pretty broken (it may not work at all with Vista's double buffering; I haven't tried). What I typically find easiest in this situation is simply to dump out image files and review then afterwards with image viewer of choice. IMHO this is actually more useful for debugging than a "live" window because you can step backwards and forwards, zoom in, apply image-enhancement to highlight various issues, compare against previous runs for regression testing etc etc. (If you really want the "live" views, write an image displayer which monitors a directory for new images, or streams them through a named pipe or something).
If you just want simple graphics, no widgets, SDL is very easy to use. If you do need complex controls, use Qt, as timday said.
You might check out IUP. It interfaces really well with Lua, and can be used entirely from an extension DLL there so it seems plausible that its C API could be used from a DLL plugged into something else.
IUP will get you a framework for opening a window containing the usual suspect kinds of controls, including a canvas. Its related library CD will give you the usual drawing operations in that canvas.
Current releases are portable between Windows and *nix. The next major release will support MacOSX too.