After a quick review of the of UWP keyboard event basics, I opened up the can of worms that is keyboard navigation. I stumbled into this because I wanted to use arrow keys to move the 3D printer carriage holding a camera, but arrow keys already have roles in an application framework! My first effort to respond to arrow keys was a failure, and I hypothesized that my code conflicted with existing mechanisms for arrow keys. In order to figure out how I can write arrow key handlers that coexist with existing mechanisms, I must first learn what they are.
Graphical user interfaces are optimized for pointing devices like a mouse, stylus, or touchscreen. But that’s not always available, and so the user needs to be able to move around on screen with the keyboard. Hence the thick book of rules that is summarized by the UWP focus navigation page. As far as I can tell, it is an effort to put together all the ways arrow keys were used to move things around on screen. A lot of these things are conventions that we’ve become familiar with without really thinking about it as a rigorous system of rules, many were developed by application authors so it “felt right” for their specific application. It reminds me of the English language: native speakers have an intuitive sense of the rules, but trying to write down those rules is hard. More often than not, the resulting rules make no sense when we just read the words.
And, sadly, I think the exact same thing happened in the world of keyboard navigation. But in a tiny bit of good news, we’re not dependent on understanding words, this page also had a lot of animated graphics to illustrate how keyboard navigation functions under different scenarios. I can’t say it makes intuitive sense, but at least seeing the graphics help understand the intent being described. It’s especially helpful in scenarios where tab navigation interacts with arrow key navigation.
New Screwdriver 
“Why can’t you just” … map the W,A,S,D keys to spit out repeated bits of G1 commands in a relative coordinate system, in order to control the movement for jogging? like, say 5mm. as long as your repeat input (from holding down for more than a certain time) fires off before the deceleration of the first 5mm movement begins, it should flow steady. I imagine you would be using slow accelerations and low speeds to avoid any imaging problems.
Perhaps the jogging commands could ‘skirt’ the UI and just spit this gcode straight to the machine. I’ll admit that I don’t keep up with your software posts, so if you ditched the entire stock printer firmware etc. please disregard.
LikeLike
That’s a valid approach to solve the immediate problem. Part of why I dove into keyboard navigation is because I thought it would be useful to learn how to “do it right”. Which took way more time than I originally expected. And if I sunk in that much time, I’m going to get a few blog posts out of it, darnit!
LikeLiked by 1 person
Well, we both know I’m the lazy one. Whatever it takes to get back to breaking stuff again, I’m there. BTW, I eagerly await the results of this project, since I have been disappointed in DIY scanning methods for years. I had some initial success with the Ciclop 3d scanner, but then I rebuilt it and re-compiled the firmware on a different computer and couldn’t get it back to it’s previous state. I don’t think I’ve done a successful scan at home since. For industry, the ATOS white light scanners are the best all around, I also find the FARO products as used on Jay Leno’s Garage to be very appealing for a small shop. So, good luck to you! The community needs more scanning methods.
LikeLiked by 1 person