How to handle screen motion of silverlight Windows phone 7 programmatically?
The motion of the phone screen is controlled entirely by the user. Whilst the device has an accelerometer which can be used to gauge motion in all three axes, it does not have any means of powering its own motion.
I would consider a couple of solutions:
Modify the hardware, perhaps add propellers to the handset. Quadrocopters are a popular configuration, giving both stability and maneuverability (they can even juggle!)
If hardware modification is not an option, you are going to have to rely on the user. I would suggest displaying a large arrow indicating to the user the direction you wish to move the handset in. You can achieve this with a single arrow image using a RotateTransform.
Hope that help.
Related
How do you handle control size on touchscreen, so it is easily used?
I have seen most examples have TextBox Height set to 40 pixels, or buttons 40x40. So, when I make controls this size and use it on my 13" Full HD device. it is OK.
However, I have noticed that lately there are laptops with very high resolution (ex 3200x1800), and small screens (ex 13-14"). How do you handle such scenarios? They usually set text (app) size to 250% in display settings, although this is mandatory.
Do we programmers need to use text (control) scaling as parameter when building UI?
Writing a DPI–aware application is the key to making a UI look consistently good across a wide variety of high-DPI display settings. Applications that are not DPI–aware but are running on a high-DPI display setting can suffer from many visual artifacts, including incorrect scaling of UI elements, clipped text, and blurry images.
link: Writing DPI-Aware apps
I have a mobile game developed by U3D and NGUI and targeted to platforms such as android and IOS, but there are so many mobile resolutions and aspect ratios change from 1.3 to event 2. My UI are designed under resolution 1136x640, and UIRoot Scaling style is FixedSize, Manual Height is 640.
I am not going to use anchors in NGUI widgets because distance is defined in pixels but not in percentages, when resolutions are changed, relative position of widgets are also changed, this is not what I want.
I refer this but still have no idea to handle this tricky problem perfectly, I need some suggestions on how to use NGUI in right way to handle different mobile resolutions.
The newest (3.x.x) NGUI allows you to use their new anchoring system. As you said, it is specified in pixels, however you can specify different targets and distances to different edges, and it will behave similarly to percentages.
Are you familiar with NGUI team videos explaining their new releases?
https://www.youtube.com/watch?v=6k5iIzKTEBQ
Some of the information there could be helpful, and playing with Custom settings of anchors either.
Another useful things is to create scaling script attached to root, which scales all elements down, basing on the detected dpi. If your UI is prepared for phones, you probably won't need all the buttons to take the same percent of the screen on tablets.
I have read about it on this link : How to using anti aliasing in wpf 3d but unfortunately, there was no answer.
I cannot seem to set the RenderingOptions of my viewport (using the helixtool/helixviewport).
Does anyone know how to increase the sharpness of rendered models?
First of all if you are running windows XP then multi sampling is off by default, there are reg changes to turn it back on but beyond the scope of this question.
WPF should use multi sampling by default, one thing you should make sure of is that your graphics card meets the min requirements for hardware acceleration with WPF Here and also that it's not disabled in the graphics card driver control panel.
using the model from the link in your question I got this, which is ugly!
the setting on my nvidia graphics card that was making this happen is displayed below.
once I changed the OFF to application controlled, WPF started to use it's multi sampling
We are building a Windows application in .NET and one of its requirements is touch screen monitor. Other than that, it's a normal windows form based application. But except for making UI items little bigger for touch, I can't find anything I as a developer need to do for the requirement since touch screen is basically mouse operations. Am I missing something?
No, you are not missing anything. Do get the actual hardware hooked up so you can test it, "little bigger" is invariably underestimating the problem of fat fingers. Everything should work from a single click, right-clicks are horribly impractical, double-clicks are best avoided.
The only other thing you'll want to do is go into the Control Panel + Display applet and change the size of standard Windows UI elements. Pick a large window caption font if you want to allow the user to drag or close windows. Make the scrollbars at least twice as wide. And the menu and message box font. Go in the Mouse applet to increase double-click range and time if you want to support that.
If you do not need touch-specific event handling I think it's all you have to do. But touch means more than that and you may want to support it in a better way: http://archive.msdn.microsoft.com/WindowsTouch/Release/ProjectReleases.aspx?ReleaseId=2127
I am currently working on the WPF project which involves creating a touch-screen application for Windows XP embedded. And as Windows XP wasn't built for touch interaction, there are some problems and issues with developing those applications.
An example would be a click: On windows XP click is mouse down and mouse up event, however if you use your finger instead of the mouse, you might get a drag motion instead of the click, as when you press mouse down you finger might slightly move to the side from the initial position and you will get a drag instead of click. This is just a single example of the problems you get when developing an touch-screen app for Windows XP.
If someone has been working on the WPF touch-screen application for Windows XP, could you share some knowledge and point out the pitfalls you have encountered or if you know of any resources on this topic, could you please share it.
I would agree with #bflosabre91. With a mouse you could have the same problems and in fact happens quite frequently when someone is learning to use a mouse. I think this problem is more relevant at the hardware level and how the touchscreen actually interprets what the user is doing.
On the software side, you COULD add some logic something along the lines of:
On mouse down: record coordinates and maybe the control (button, etc.) that is under the pointer
On mouse up: compare recorded coordinates with current coordinates. If it's within x pixels, either do a "control.click" or move the mouse to the old coordinates and tell tell the mouse to click.
The hardware may already be doing something like this...
i have a WPF touch screen application and it is running on kiosks with XP(although its not XP embedded like you said). I haven't had any issue with any type of click event or anything like that. I programmed it using all the normal mouse click events so it technically does work with a mouse or with the touch screen. As long as you build the controls to be large enough to account for the fact a finger will be touching it instead of a mouse pointer, I did not come across any issues.