I need to find what key the user pressed on a keyboard using xamarin.forms, ideally inside an AbsoluteLayout. I've come up with a few ways myself, but can't get any of them working.
As there isn't an event for this on the AbsoluteLayout control, i tried a little cheat, which was putting an entry field (textbox) on the screen, but hiding it above, so it can't be seen and using the result from that, but it loses focus when someone presses the screen or a button on the screen. so i tried adding an event to each button which refocuses the textbox once i've handled the press and this seemed ok at first, however, if they press anywhere else on the screen, it also loses focus.
I also tried adding a TapGestureRecognizer to the screen, and focusing the button when they press anywhere on the screen, however, there were 2 issues with this, the first being that it appears to only fire when something inside it is touched, and secondly, when i call the focus method for the second time (if they click the screen twice) it un-focuses the entry field, even if i check "isfocused" first (think this is a bug).
I'm only concerned about windows 8 and android apps so far. iOS may come later, but for now im just trying to get it working for these OS's. so maybe i could code it in the windows and android projects (inside my shared project solution), however, i have absolutely no idea where to even begin doing that. I mean, if this is the best way, how can i pass my AbsoluteLayout to the windows project and get it to know what it is, and convert it into a control which i can then add the event to.
Any help or advice, or ideas would be much appreciated. I cant find anything in NuGet which will help me with this. Any ideas?
Many thanks
James
Related
My AutoIt script simulates mouse clicks. First a right click in one place, then a left click in one of many other points. I achieved that with MouseClick() and it works fine.
But now I want the script to work in "background" so I used ControlClick(). But there's no control ID. This is what I tried:
$square = Floor(Random(0,$length)) ;this one gets length of array with coordinates
;MouseClick("right", 1634,195 ,1,1) first version-works fine
ControlClick("Medivia","", "", "right",1,1634,195)
;MouseClick("left", $cordX[$square], $cordY[$square]) first version-works fine
ControlClick("Medivia","", "", "left",1 ,$cordX[$square] ,$cordY[$square])
The script clicks, but only in the place where I leave the mouse pointer. It does not move the mouse pointer by itself. Could anybody help me?
Answer Limitation: To use any of the Control* APIs from AutoIT, you're going to need to be interacting with a real Windows control.
If you just want to do "random" clicks, you probably don't need a real Windows control and should not be relying on ControlClick.
If you're trying to click on the "background" of Windows, you probably want to just minimize all open windows, which you can accomplish with WinMinimizeAll.
GUI clicks with Qt and other frameworks without real Windows Controls
Some frameworks like Qt will not give you a real Windows control for many of the default GUI buttons and the like, so when using AutoIT's Windows Info tool, as well as many of the UI spy tools out there, that info will be missing.
What you may need and I currently need is to resort are workarounds. For your case, it would help if I could see a screenshot of the sequence you're trying to automate; I could give better advice after seeing that.
For my case, I needed to click on a Quit button that had no controls and the developer told me he didn't have a way (or know a way) to add accessible names to the pop-up I was trying to hook into, even though I could hook to the main app's hWND. Luckily, that quit-box had a special color for the Quit button, which allowed me to use AutoIT's PixelSearch to locate it.
When you don't have cool helpers like that, it's usually best to determine the location of the main window, and whatever pixel-offset you need to find what you're looking for.
Please see this gist to see what I am trying to achieve: https://gist.github.com/d9e22915234e6ea34d20
The code is heavily cut down on the problem I face. As you can see when running the code there is a "miss" detected on the label or the text area (if you miss it by 5em or whatever). Unfortunately this does not work for the Dialog's own buttons OK and Cancel (Please run the code and you will see immediately what i am talking about). If you click near an FX-Node it should detect wheter you missed it or not.
Does anybody know if it is possible to detect clicks in the Dialogs button area?
And if it is possible, how to link them to the node like the label and the area?
Thank you in advance.
From what you're seeing, I would guess that the Dialog consumes click events in the button bar, so they don't make it to the Window (which is where you added the EventHandler). If you really want to do this, you can change addEventHandler to addEventFilter. This works for me.
Read this tutorial if you want to find out why this works:
http://docs.oracle.com/javase/8/javafx/events-tutorial/processing.htm#CEGJAAFD
I have two options. I need 48 of a certain type control; it needs to respond to clicks and taps (for touch devices).
I could use Buttons, using the TextButtonStyle, and the Click event. Or I could use TextBlock, with the Tapped event.
I reckon buttons may be more "expensive" to create. OTOH, although I believe "Tapped" is also called when the user clicks the component, this makes me a little nervous due to its nomenclature, I guess.
Another difference is that a button takes up only the width necessary, whereas a TextBlock takes everything; and I want the underlying Grid to be tappable, so the TextBlock is kind of a problem that way. Is there a property that will make it more modest like the button?
There is design guidance for Windows Store apps on when and how to use buttons at http://msdn.microsoft.com/en-US/library/windows/apps/hh465470. Based on your description and this guidance, it sounds like buttons are the way to go. Responding to click events is what they were made for, and TextBlocks add the extra issues that you describe.
I have a Flex app I built. It uses the BrowserManager class to listen for changes in the # part of the URL. When a change is made to the hash my application updates accordingly so you can link directly to a state of the application. Also inside my programming when a user clicks something, all I do is use the BrowserManager to update the # and then my listener will apply the correct changes once its finished. I believe this is the best practice way to doing this in Flex.
I have some issues though. When using the Back button in FF or IE, it gets "stuck". for example if the hash is like #state4 clicking the back button will take you to #state3 then #state2 but sometimes get stuck where you can be on #state3 click the back button, see it flicker to #state2 real quick then change back to #state3 preventing you from going back any further in your history.
Now in Chrome its even worse. As you make your way through the application the hash # is updated and so the application updates (proving that the app can see changes in the hash since thats the only way it updates). but when you click the back button, the hash # goes back to its previous state, but my application does not as if it is unaware the hash is changing.
I find this very bizarre and don't know what to make of it. I was wondering if anyone else had experienced this or knows what might be the issue.
To see it in action go here and navigate the builder (it will ask you to click jewelry type, metal, etc.) a few times until you see the big red add to cart button, then try to use your back button to get back to this page.
Have you tried the History Manager. Have a look on the http://www.nbilyk.com/blog/1/68/flex-history-manager
Just wanting to know if anybody has seen an example of a telnet/chat or other console like FLEX application where you can use the same TextArea as input/ouput area.
I've been trying to modify the app at:
http://livedocs.adobe.com/flex/3/html/17_Networking_and_communications_8.html
but so far, computer says no.
All the implementations I've seen use a combination of TextInput and TextArea.
The challenge is that we'll be using this app to telnet into some old routers and we'll need to do a fair amount of copy/pasting. Based on what I've seen, it seems that I would need to point the mouse into the TextInput in order to be able to right click and paste, which is not very sleak.....
Your thoughts,
Fran
edit Just realized that I had trimmed out what was directly pertaining to the question: I was unable to find anything that used the TextArea for input and output; see the below suggestions if custom-component suggestions are ok.
The TextArea component only fires a change event whenever a user adds input. Whenever you set the text field programmatically, a change event does not fire--you could maybe use that as a way to know what is user input and console "responses" by looking for carriage-returns (\r).
I'm unsure if you have a requirement to maintain the user's input at the bottom-most line (like a console), even after the console responds with something like auto-complete. If that's the case, then something a bit more complex would have to come into play (such as remembering where the user's input started/ended) or the requirement of a single-component console needs to be reconsidered--sleek is nice, but not always necessary.