First of all, sorry for my English ^^
I'm blocked a problem with sending messages with SendInput and touch screens
Here is the detail of the problem :
I have an application that recovers touch inputs in Raw with "RegisterRawInputDevices"
Then I translate these entries into gestures such as a pan, scale in/out etc ...
Then, using gestures, I send mouse / keyboard messages with SendInput
The problem is that there is an system on the Windows side that does much the same thing, and it conflicts with my application.
For example, when I make a movement with 2 fingers on the touch screen, I send a mouse movement message with the average of the 2 points as position (see image)
Touch sample bug
The cursor is therefore positioned between my 2 fingers (green) but from time to time the cursor jumps to one of the 2 fingers (red)
It seems that the problem is related to wisp
I tried the technique indicate here.
The TouchGate registry no longer exists in “Ordinateur\HKEY_CURRENT_USER\Software\Microsoft\Wisp\Touch”
But it is present here : Ordinateur\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Wisp\Touch
If I set the TouchGate value to 0 and restart the computer, this partly solves my problem because Windows no longer adds messages and I still have touch inputs from the Raw
The problem is that this technique requires a restart of the computer and that it is applied on the whole system whereas in the ideal I would only like to remove this layer for certain applications
I obviously tried to add this value in HKEY_CURRENT_USER and also tested the technique of updating windows with “SendMessageTimeout” and the message “WM_SETTINGCHANGE” but without success
Another sample with video, my app use SendInput from my finger pos and add -100 to y position :
https://streamable.com/af8u3
Summary of my request
How to remove the system (wisp) or others multi touch overlay of Windows, dynamically (without restarting the machine)
Related
I am coding a game on a Touchscreen with many players at the same time. The issue is, when there are 2 or more touches, a little square is appearing on the screen. It seems to be a unity built-in feature as it is still present in an empty project.
Is there a way to prevent this annoying little square to appear ? I already disabled magic touch shortcuts in windows. And this doesn't appear on the desktop home screen.
I am able to listen to the touches. It seems to be only a visual thing.
Even when I disable multitouch with Input.multiTouchEnabled = false; It still appears.
I also tried to remove the 18 default Axes in the Input Manager.
My goal is to handle every touch separately, without listening to pinch, long press, or scroll interactions. Each player has only to tap somewhere on the screen.
Thanks for you time
Solved it by myself. I completely disabled Touch feedback in the windows parameters. I don't think it is the only way to do that but it works.
Configuration Panel > Pen and Touch
Unmark "Show visual feedback when touching the screen"
A bit of background: I recently implemented a Drag and Drop Behavior to my app, where I can drag items from e.g. the Finder inside my NSTableView. Now I wanted to write a few ui-tests for this new functionality.
The general idea was to move the finder window to the left side of the screen and my application window to the right side of the screen and then execute the drag and drop. The drag and drop itself is not the problem, the problem is the setup of the mentioned window layout. I cannot find a convenient way to resize and move the two windows. Coming from .net, I expected something like app.window.setSize(..) or app.window.moveTo(...).
What I tried so far:
As I have Magnet installed on my Mac, I tried the easy way out and sent key-events (control + option + arrow) to the window. This did not work, sending the keystrokes results in an error beep. Doing this manually during the tests works, so I don't know what exactly stops Magnet from rearranging the windows, but I guess it has something to do with the Testing Framework. I did not dig deeper into this, as it would have been a cheap solution anyway.
Drag the app window corners based on screen dimensions, e.g. for the window on the left I drag the corners to the top left, bottom left, top middle and bottom middle of the screen. This requires that all four corners are visible on screen, but that's a problem for another day. The solution would normally work, but the problem is that the y-coordinates I get from the frame of my app window are not what I was expecting. I do receive the location of the app window with app.windows.firstMatch.frame.origin. The x-coordinates look alright, but the y-coordinates are totally off (from what I expected).
I can't find many resources regarding the origin or frame members. Any idea on how to face this problem or where to find a documentation about the XCUITest-Framework and the basic concepts behind it? The official documentation doesn't help in this case. I only found this short explanation in the apple documentation archive about the coordinate system of macOS (or OS X back then) applications.
I am currently running Linux Mint 17.2 with Cinnamon. I have 2 monitors.
When I set monitors to be adjacent in Cinnamon settings, mouse freely moves through border shared between monitors but cannot escape visible area.
That is, if I set monitors to share only corner, mouse is effectively locked to current monitor and can escape to another only through corner.
However, setting monitors to be non-adjacent allows mouse to roam freely all over virtual framebuffer, including invisible areas.
I thought that Cinnamon sets some flag that controls this behavior, but changing monitor position using xrandr has the same effect.
Also, it is the same when I start plain Xorg with nothing but xterm, even without a window manager, and configure monitors using xrandr.
What exactly stops mouse from leaving visible area when all monitors are adjacent? Is there a way to override this behavior?
Being able to control this might be useful e.g. to stop mouse from leaving monitor every time you try to click something near border, without running a busy loop that monitors mouse and moves it back if needed (and without doubling framebuffer size by making monitors be adjacent by corner).
With more control it can be used to e.g. make mouse "reluctant" to leave current window, and maybe do other fun stuff. At least it will make it possible to reimplement this thing so that it can actually lock mouse to window for apps like Chrome browser or OpenGL games and not just xterm and the like.
Now that I think of it, I may even try to implement it, if it is not yet and if I find relevant code.
Okay, I have found the relevant code.
This behavior is hardcoded in Xorg X server, in RandR extension, including visible area continuity check.
Definitely nothing configurable. Well, unless you agree with creator of dwm on what the word "configuration" means :)
I do agree. Right now relevant code locations are randr/rrpointer.c and
randr/rrcrtc.c:332,1685.
Would be nice though if someone created a proper X srver extension for that.
As you already figured out: if your monitor areas are non-continuous, it seems that xrandr will allow the entire x11-screen to be used by the pointer. I just purposefully moved the position of one by 1 pixel (option --pos with xrandr) to free the mouse.
Once the mouse can go everywhere, it should be possible to fence it in with pointer barriers:
http://who-t.blogspot.com/2012/12/whats-new-in-xi-23-pointer-barrier.html
That requires the XFixes extention version 5+ and gets enhanced with XInput as described in the link with events and temporary barrier lifts... which is probably not required here.
In gamesalad framework I am creating a game in which I have an actor which only moves on x-axis on touch is pressed. But when I move it to x-axis the actor goes away out of the range of the screen. Let me clarify that I am new to gamesalad framework.
plz help to solve the problem.
I'm reading this in two different ways:
1 - when you press your touch controls the actor disappears from the screen
2 - when you press the touch control the actor moves along the x-axis and out of the screen
For the sake of argument I'm going to assume that we're talking about number two.
What you'll need to do is restrict the actors movement to the boundaries of the current screen. You can do this is two ways with Gamesalad
1 - create an invisible barrier for your actor to collide against
2 - use a behaviour to prevent your actor from going beyond the screen boundary
I'll explain both:
1, Invisible barriers
What you'll do is create a new actor, and set it to collide with the actor that your controlling. You'll create a few instances of this actor to create a walled area for your actor. Although this works, it's a little cludgy and using additional actors in a scene take a little performance away from your application.
2, using a behaviour
In my opinion the better way is to use the given behaviours in Gamesalad itself.
To stop the player actor from moving off screen you can use a combination of Rules and the Constrain Attribute behaviour to achieve this.
The first thing to know is your screen size; for an iPad I believe it's 1074 along the x-axis.
So to stop the actor moving off either side of the screen you'll need to do the following:
Open up the player actor
the click on the "Create Rule" button on the top right.
A new rule window will appear, but default the first dropdown will say "Actor receives event" change this to "Attribute".
Next select the attribute to use the rule against, since we're interested in the x-axis we'll want to query that player attribute which will be:
(also known as self) > Position > X
Select the greater than symbol (">") and then enter the maximum width of the screen minus whatever border value you want, so I'll use 1014 (1024 - 10).
Find and drag the Constrain Attribute behaviour into your rule a set the actors X position to 1014.
This will stop the actor from going beyond one side of the screen, now copy the rule and amend the settings to that if the actor goes less than, say 10, it will constrain the actors X position to 10.
I'd post an image, but alas my Karma isn't large enough right now! Hence the large explanation!
Hope this is what you're looking for!
It is way easier than that.
In top of the Gamesalad Creator there is a play button, which you probably know, displays your progress. To the left of this button there is a button that looks like a little video camera, it changes the camera settings. So what you first have to do is click the camera button, then the rectangular camera screen will show itself as marked. In the center of each of the sides of the highlighted rectangular which is the camera screen, sits 1 little grey rectangular. Each of these needs to be pulled to the center of the camera view so that you get a little grey "cross" in the center and from the center to the boarder there will now be this highlighted color.
Second and last step is easy, just go under your character and in (type or drag in a behavior block) you type control camera... or drag the control camera block, which as by the type box is statet possible.
Since Gamesalad only can have one camera at a time, and you character is the only one with the control camera option applied it will follow him and only him. Wherever your character starts on the screen, the camera will follow it when it passes through the center of the screen. You may know this from Super Mario Bros. Where you start of a little to the left and walk right and the second Mario enters the center of the screen, the camera follows him from then on.
Hope this helps... :
I'm starting a new project which involves developing an interface for a machine that measures wedge and roundness of lenses and stores the information in a database and reports on it. There's a decent chance we're going to be putting a touch screen on this machine so that it doesn't need to have a mouse or keyboard...
I don't have any experience developing for full size touch screens, so I'm looking for advice/tips/info from you guys...
I can imagine you want to make the elements a little larger than normal... space buttons out a bit more.... things like that... anyone have anything else to add?
A few things to consider:
You need to account for parallax error when touching controls. Basically, the user may touch the screen above or below your actual control and therefore miss the control. This is a combination of the size of the control (eg you can have the active area larger than visual control to allow the user to miss and still activate the control), the viewing angle of the user (which you may or may not be able to predict/control) and the type of touch screen you're using. If you know where the user will be placed relative to the screen when using it, you can usually accommodate this with appropriate calibration.
Depending on the type of touch screen, you may need to ensure that your users aren't wearing gloves or using an implement other than their fingers (eg the end of a pen) to touch the screen. Some screens (eg those depending on conductance) don't respond well to anything other than flesh and blood.
Avoid using double clicks because it can be very hard for users to reliably double click a control. This can be partly mitigated if you've got experienced/trained users working in a fairly controlled environment where they're used to the screens.
Linked to the above, if you are using double clicks, you may find the double click activated when the user only wants to single click. This is because it's very easy for the user's finger to bounce slightly on touching the screen and, depending on how sensitive the double click settings are, trigger a double rather than a single click. For this and the previous reason, we always disable double clicks and only use single clicks (or similar single activation controls).
However big you think you need to make the controls to allow for touch activation, they almost certainly need to be bigger still. Make sure you test the interface with real users in the real deployment environment (or as close to it as you can get). For example, we deployed some screens with nice big buttons you couldn't miss only to find that the control room was unheated and that the users were wearing thick gloves in the middle of winter, making their fingers way bigger than we had allowed for.
Don't put any controls near the edges of the screen - it's very hard to get your finger into the edges (particularly if the screen has a deep bezel) and a slight calibration problem can easily shift the control too close to the edge to use. Standard menus and scroll bars are a good example of controls that can be very tricky to use on a touch screen and you should either avoid them (which is preferable - they're not good for touch screens) or replicate them with jumbo equivalents.
Remember that the user's hand will be over the screen, obscuring some of the screen and controls (typically those below where the user is touching, but it depends on the position of the user relative to the screen). Don't put instructions or indicators where the user's hand or arm will obscure them when trying to use the control they relate to (eg typically put them above rather than below the control).
Depending on the environment, make sure your touch screen is suitably proofed against dust, damp, grease etc and make sure it's easy to clean without damaging it. You wouldn't believe the slime that can quickly accumulate on a touch screen in an industrial or public setting.
The other obvious one is that there's no equivalent of pointer 'hover'. Not that that affects many apps though.
If you decide to put in analog controls (scrollbars, rotation widgets, etc) be sure to put in a digital control also. Some companies think that a touch screen means perfect control over something with your fingers. In real life, this translates to minutes of frustration trying to fix a number that's just a little off.
The most obvious thing is that everything on the GUI needs to be big enough for a fingertip to hit, which is sometimes bigger than you think.
As has been mentioned, there's really no way for a right-click action to happen. Also, double-clicking can be tricky with a fingertip on a touch screen.
The other major thing is that you'll want to create a on-screen keyboard that pops up for text entry and an on-screen numpad for number only fields.
I wrote my own set of controls for a POS application designed specifically to be touchscreen friendly.
Remember to allow enough real estate for stubby fingers and talons. In our application the users can have these manicures that necessitate them to use the pad of their finger instead of the tip. This means that you need to allow more space for activation areas than you would normally consider in any other type of application.
I would also recommend that you accommodate yourself as a programmer from a testing standpoint and from the point of view that things change and there may need to be a keyboard/mouse attached to a non-touch workstation. I cannot tell you how many times I went to touch my flat panel LCD expecting something to happen, before remembering that I had to use the mouse.
Make sure to read your basic UI principles like Fitz law (The time to acquire a target is a function of the distance to and size of the target).
Also consider whether or not the device is stationary or not when it is in use (e.g., like a palmpilot or iphone), research shows that you must accomodate that into your design.
The larger gui elements is the major thing. But it applies to all elements, scroll bars, tabs and even text fields.
The other major thing that I can think of, it's hard for the user to right click. So things that require a right click should be avoided, context menus are the only thing that comes to mind at the moment.
The other responses are pretty good, but are you totally sure that a touch screen would actually be easier to use? There are a lot of devices where a touch screen actually makes them much harder to use, not easier. The main problem is that you can't use the device when you're not looking at it. If users are going to be doing a lot of repetitive actions, a keyboard could be a lot more efficient.
Also, a touch screen might be a lot harder to use by someone with a disability, if you think there's even a small chance that could happen.
Even though this is quite old now, I found it to still be useful, as a starting point for design considerations.
http://www.sapdesignguild.org/resources/tsdesigngl/index.htm
If you've not already done so, have a look at some of the documentation available for developers on mobile platforms, eg Windows Mobile, iPhone.