I have a modeling application for a Windows desktop (it will run on Windows 8) that includes a 3D environment. Currently, it can only handle mouse and keyboard input. I have been searching for several days on how to add gestures or touch input to legacy apps, or if it is even possible. If anyone knows where to look, I would greatly appreciate it.
Related
I am using Windows Forms application and I am not able to auto hide/show the touch keypad thats on the windows 10 Home OS on a tablet. How to handle the touch keypad, Can anyone help me out in this regard.
There's quite a lot of answers on google for this,
https://www.google.co.uk/search?source=hp&q=vb.net+hide+show+touch+keyboard+windows+10&oq=vb.net+hide+show+touch+keyboard+windows+10&gs_l=psy-ab.3...1296.11486.0.11948.28.27.0.0.0.0.75.1723.27.27.0....0...1.1.64.psy-ab..1.20.1290.0..0j0i131k1j0i67k1j0i22i30k1j0i13i30k1j0i8i13i30k1j33i22i29i30k1.TfxlEFKhnRI
Basically you need to create a process for the OSK, load it, and kill it (dependant on if its loaded). Loading and killing the process will show / hide the OSK.
After Googling for about the past hour and a half, I have been unable to find out any definitive information on how the start menu and how windows 8 style applications work behind the scenes. I was under the impression that Windows 8 Style applications were processes which created fullscreen windows and that the Windows 8 start menu was created by explorer.exe in much the same way. But there are incompatibilities between Windows 8 the 1.x version Sysinternal's Desktops utility, I have to imagine that something more complex is going on.
However, in Spy++, each Windows 8 style application appears as standard Window with the WS_EX_TOPMOST style set, which would make sense, assuming they are nothing special. With respect to the Start Menu, it appears as a window of class ImmersiveLauncher created by explorer.exe. Perhaps explorer has developed an aversion to having multiple instances...
Using the old version of SysInternal's Desktops, the explorer instances in the additional desktops work fine, but do not load pinned items nor load the desktop background and icons.
Is there any documentation on why Windows 8 behaves differently from past versions when multiple copies of explorer.exe are running in different desktops?
(This is purely for curiosity's sake)
(Yes, I know there is a Desktops 2.0 version available which supports Windows 8, but it uses interesting workarounds, like switching to the original desktop when the windows key is pressed. It also seems to trigger some initialization within explorer.exe when the desktop is loaded for the first time beyond simply starting the process.)
I've started doing Windows 8 Store app development for some projects at work, but I do not have a touch screen device of my own at home. If I write a personal app for submission to the store, I must use my own hardware since I can't use the work computers for personal projects. My concern is getting into a situation where I submit an app to the store, then have touch-screen users describing issues that I can't replicate on a non-touch-screen device.
Are there any functions or capabilities or interactions that behave differently in a Windows 8 store app when using touch vs. using only a mouse? Are there any scenarios I could encounter where I would be at a loss to reproduce or troubleshoot a user's problems if I do not have a touch screen?
As Konstantin suggested, a tablet is strongly recommended.
The next best thing is to use the device simulator in Visual Studio. It will let you change screen sizes, and allows you to simulate basic touch gestures with the mouse. This MSDN link has more info: Testing Windows 8 apps using Visual Studio 2012
Microsoft have introduced events that are pointer agnostic meaning that they should function the same way regardless of whether you are using a touchscreen, a mouse or a pen. Those are the MSPointer events. Here's some documentation. Using event handlers for these events mean that you should not be getting complaints from users about the touch friendliness of your application. However I still strongly suggest that you acquire a surface and test your application on it. Not just for the touch friendliness but also because of performance differences.
I have a game that I'm porting to the Windows Store, but unfortunately, the game genre doesn't really work well with touch input. I currently support keyboard, mouse, and gamepad, but I'm worried that I will get rejected because I don't handle touch.
Anyone have experience with this or know where I can look?
Found the answer here: Windows 8 app certification requirements
3.5 Your app must fully support touch input, and fully support keyboard and mouse input
Your app must provide visual feedback when users touch interactive
elements.
Which is a bummer because now I'm not sure how one can publish a game to the store that just doesn't make sense with touch input.
I have a Windows Phone 7 application and I regularly see "weird" UI glitches that take me AGES to debug. It's a range of issues like controls appearing to have extra margin, scrollbars not appearing, animations looking really glitchy, entire page scrolled down, combobox items offset, etc. etc.
I'm happy to admit it might be me - but how to you debug UI errors like this? I know there's Silverlight Spy for the PC Silverlight Apps. Is there anything like this for Windows Phone 7?
Any debugging tips v much appreciated.
I have found that it is a good idea to start with Windows Phone 7 Design Templates, adopt a version control system right from day one of the project and to edit the XAML, use Expression Blend. The Visual Studio is great for writing code, but, to harness the real power of the tools, Expression Blend is the best to style your application.
HTH,
indyfromoz
Here are some tips:
Many people have issues with the emulator due to their graphics card.
Things like slow animations and ui glitches are very common.
Check that your graphics card is Direct X 10.1 at least and that your Driver
Model is WDDM 1.1
Make sure you have the latest drivers.
Windows 7 has less issues with the emulator than Vista
Make sure you have the latest tools, get the RTM release from the website.
In the RTM release, the frame rate counters are displayed by default in a vertical bar on the left, you should monitor these to check for performance issues
Here are a couple of things which I normally do... none of them are real smart, but sharing nevertheless.
Deploy it after every 2-3 controls that you add and ensure things are correctly laying out.
If by chance it doesn't work the way I am expecting it to, I have a parallel Silverlight 3 project running in which I typically paste the XAML and see if it works fine.
After that, I typically check it out as a Silverlight project since even I am not sure of any tools available for Win Phone 7.
I have favorited this question and I hope someone points us to something more interesting.
There's a lot you can checkout with Blend as Indy suggests. This is really good advice.
Regarding some of your specific issues these aren't necessarily glitches. I'll comment on a couple that stand out.
Extra margin - this and padding are built into the metro controls by design. Again, in blend you can dig into this by retemplating the control and changing properties of objects within the control.
The procedure for this is rclick the control, edit template, edit a copy. Then you can look at the different states and objects and change things as suits. While doing this please keep in mind the App Certification Requirements and UI Design Guidelines.
Regarding scrollbars, these are by design hidden until you start scrolling. You can control their availability with Horizontal/VerticalScrollBarVisibility on relevant controls (or on the ScrollViewer embedded in some controls - again retemplate in blend).
Combobox isn't metro themed so is going to struggle in the fitting in department, but there are posts around where people have done work on this. ListPicker is a better fit imo from the Windows Phone Toolkit released with the RTM tools.
If you can't see any obvious causes for the glitches in your code the first thing I would recommend is to actually test your app on a real device. Somethings - particularly animated objects -don't always look exactly the same when you run them on a device.
I thought I had a animation glitch in one of my apps but it only appears in the emulator. When I run on an actual device I don't see it.
Of course this doesn't help you if you can't get a phone to test it on yet, but before you potentially waste hours trying to debug a problem you might not have I would work on the rest of the app until such time as you can test the app on a real phone.
The same goes for anyone creating animations - don't waste time perfecting animations in the emulator. The timings will almost certainly be different on the actual device, so wait till you have one to test on.