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.
Related
I just started developing a test automation for an iOS app using Appium. I have to click several buttons in the app one after another with different XPath/Accessability ids.
I wondered, when to use the wait.until(ExpectedConditions.visibilityOf Element) expression.
Example:
wait.until(ExpectedConditions.visibilityOfElementLocated(By.xpath("//XCUIElementTypeApplication[#name=\"app\"]/XCUIElementTypeWindow[1]/XCUIElementTypeOther/XCUIElementTypeTabBar/XCUIElementTypeButton[3]")));
Should I check every time before I click a button if this button is actually visible or existing on the current state of the app or is this just unnecessary and time-wasting?
In my opinion, you should use ExpectedConditions in two case:
Screen load takes long, so you not ending up trying to click something that has not loaded yet. If you find your tests flaky (sometimes pass some times fails) then this probably the main reason why it happens
If you have something like ajax on your screen you want to make sure the data is changed on the page. (Example is you created a post on Facebook, and want to make sure content displayed)
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
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.
I want to create a combobox in flex which will take three values, Available, Unavailable, and Busy. The constraint is, I should not allow user to go directly from Unavailable to Busy. So when a User is selected Unavailable, I should keep the Busy item disabled (unselectable), but a user will be able to go directly from Available to Busy. I chouldn't find a straight forward way to disable an item in combobox in Flex. How can I do that?
Have you considered using radio buttons rather than a combo box? It's clear how to do this for radio buttons, for one thing. Also, it can often be friendlier to present the available options without requiring a click to reveal them. (Especially if, as in this case, you are adding the possibility that an option is "available, but not possible for you right now for some reason not shown in this combo-box item").
If you really want a combo-box, you can use the click event to display it in a non-standard fashion by probably changing its style; and then, if clicked anyway, Then, in the selected event, reject the choice (hopefully with an indication of why),
Or, if you want to simply remove it from the list, you can have the click listener event repopulate the source list each time, based on conditions. But that might be confusing to the user, too.
You can also have a look at
www.stoimen.com/blog/2009/03/05/flex-3-combobox-disabled-options/
which references
wmcai.blog.163.com/blog/static/4802420088945053961/
(note for NoScript users you must have 163.com and 126.com at least temporarily allowed to be
able to properly see this page)
it works very well even though I added the code for being able to properly handle keyboard
events in the dropdown list
Full self working example available at
http://olivierbourdon.homedns.org/OpenSource/combos.zip
Thanks again for the good work