Does anyone know how programatically:
1- Stop the SpinnerList from spinning;
2- Check in which item the spinner currently is while spinning;
The SpinnerList I am using comes from the mobile.swc components. It is a Spark component (using Flex 4.6). What I could take from the documentation is basically that I could control the SpinnerList and stop it when the user triggers a mouseDown event by manipulating the scoller used in the SpinnerList. That leads to another question how do I control the scroller. Do I need to set the scrollPolicy on/off? Isn't there a better way?
Second point I still have no idea how to do it. Even reading carefully the documentation. My dataProvider is sorted alphabetically and I would like to smoothly pop a letter showing in which letter group the Spinner entered while spinning. Sort of a first letter displayer that dynamically changes while scrolling. Something like the caret_index would be cool but it only updates once the Caret is selected.
Thanks!
Related
I am new to sikuli.
I am using it for functional test automation of my java spring standalone application. I am having the same set of images(logos) at multiple locations on the screen. and they are generated dynamically as per the application data. In that case how can I find and click on certain buttons/elements in the UI.
Example: like, share, comment text/image will be there several times in facebook page. in that how to we click on particular buttons out of all.(facebook is just an example) i want the similar solution for my application.
I think what you're asking is- given a case where the same image or UI element is present multiple times on the same page, how can I specify one of these elements in one location versus the same element in another?
The quick and easy way to do this would be to capture a larger picture, like as much of the window as you can, and click the image in parentheses after the click action; this opens a window reading file, matching preview, and target offset. Click target offset, use the mouse wheel to zoom in, and click on the exact point of the picture that you'd like to click.
It's possible to click in multiple places on a captured image, provided you use different click() commands, and you can set the target offset for each click() command without needing a new picture.
With just this one image, you can potentially click every square on the board provided you take the time to set the offset for each of the 64 click() commands it'd take to do so. http://files.chesscomfiles.com/images_users/tiny_mce/cigoL/Chessboard.png
The more difficult solution would be setting up regions, and searching those regions for the matching pictures, but for what you're looking for this should- for more about regions and setting it up check links below. Cheers!
http://sikulix-2014.readthedocs.io/en/latest/index.html
Based on your FB example you could use setROI() to focus on the top post on the page (imagine a rectangle that covers a complete post on the news feed) from there I would loop:
if exists(profile pic):
click(like button)
elif exists(profile pic 2): # If you are testing more than one user
click(like button)
else : type(Key.DOWN) #repeat as needed
Getting the next post into the ROI may be tricky but using WHEEL_DOWN may help if you can adjust your lines traveled with each wheel click on your system.
Pretty new to windows phone development...
I'm trying to create an input view that contains a number pad for inputting a sales amount. I know that if you were inputting a number into a text box, you can set the input scope to numeric and then when you click in the text box, a number pad will come up but that's not what I'm trying to do.
I quite literally want the lower half of this screen to be just a number pad that is always up. There is no text box. Rather, as the user is punching in numbers, it'll be displayed in a textblock (a lot like you'd see in a calculator app). I'm not seeing a control for this and google just keeps bringing me back posts about InputScope. I was even thinking of maybe a hack-around where there's an invisible textbox that always has focus, causing the numberpad to always be up, but I don't even know how to cause that behavior either.
Is there a control or technique for this or am I going to have to roll a new user control? Can anyone point me in the right direction?
I would recommend creating your own custom control. That would be the best solution for your condition. There is no inbuilt solution for this situation. I was stuck in the same condition and created a new control with a custom keyboard and a textblock.
And for the hack you mentioned. You can register the LostFocus event of the textbox control and focus the control again using Focus() method of Textbox everytime is loses focus.
I have a GridView in my main app page and I want to do some background processing for the items that are currently in view for the user (high priority), and then of course do the other items too (low priority).
I can access the ScrollBar and the ScrollViewer, but none of them appear to tell me which of my items are in the current scroll window. I could try to hack this in, but it gets tricky because the number of row/columns change based on the size of the scroll region.
http://msdn.microsoft.com/en-us/library/windows/apps/br209745.aspx
http://msdn.microsoft.com/en-us/library/windows/apps/windows.ui.xaml.controls.scrollviewer.aspx
Any help much appreciated!
thanks
There are two general ways you can do this. The first is to get the GridViewItem's AutomationPeer, which actually has a direct method to call. Class information here. I've had problems getting this to actually be usable though. Luckily, there's a second answer. It will require some math to be done, but it's doable.
Get the item container, in this case a GridViewItem, using the GridView's ItemContainerGenerator.
Get the GridView's ScrollViewer. You can search for FindVisualChild<T> methods, there are plenty around.
Do MyGridViewItem.TransformToVisual(MyGridViewScrollViewer).TransformPoint(new Point(0, 0)); This will get you the top left corner of the item, relative to the entire scrollable panel (known as its Extent) of the ScrollViewer (this will be important later).
This will return to you a Point object.
Next, we'll need to find out the range of X values that are currently being displayed in the ScrollViewer.
Note: If you're using a Vertical scrolling ScrollViewer, use the Heights. Horizontal, use the Widths. Both, use both. I am going to do my example using the Horizontal/Width.
Take the HorizontalOffset. This is your current 'lower bound' for the current viewable region.
Take the HorizontalOffset plus the ViewportWidth. This is the upper bound of the current viewable region.
If your Point.X is greater than your lower bound and less than your upper bound, then the item is visible.
If you further need to find out if the whole item is visible, do
this same calculation for Point.X + GridViewItem.Width.
Hope this helps, and happy coding!
You can use VisualTreeHelper to scan the visual tree as Nate suggests, but this is usually not recommended at runtime, especially for tight loops (e.g. checking lots of GridViewItem objects) or complex visual trees. You could do a minor improvement and only calculate the position of these items once and then do a simplified check based on the ScrollViewer.ViewChanged event and offset values, but that still seems a bit too complicated.
If your GridView uses an ItemsPanel that supports virtualization (e.g. the default WrapGrid) - most of the items that are actually loaded into GridView items are actually visible or not far off the screen, so if you bind your GridView to a collection of view models using ItemsSource - you can figure out when these items are accessed by binding to their properties or handling Loaded/Unloaded events on the ItemTemplate and call back to the view models to know when they are getting accessed. That way you can start loading these items when they first start showing up on screen and leave the logic to determine whether they should be loaded to the list control virtualization implementation in the platform.
The Spark List with a mobile theme has kind of a weird behavior that I need to disable in favor of a context menu.
The default behavior of that list is that an item only loses it's selection color when another item has entered the selected state. That means that for the moment the user remains in the down state on an item (either by mouse down or tap and hold), two items show the selection color, the one that is still selected, and the current one with the down state.
What I need is that selected items lose their selection color/state as soon as another items enters the down state, so basically the selection state needs to be set as soon as the down state is entered.
Why do I need this you may ask, let me explain;
My lists need a context menu which will be opened on long press. And since long press doesn't include a mouse up event before the long press event is triggered, the item won't get selected, thus other items won't lose their selection color.
My itemRenderer is a standard LabelItemRenderer written in AS and it would be great to change this functionality in the ItemRenderer, not the parent component.
Has anyone got a clue how to accomplish this?
Since you're using the LabelItemRenderer, I assume you're building a mobile app. This is kind of a guess; but...
Can you add a Long Press event handler to the itemRenderer, and change the selected property of the itemRenderer in the event handler?
I'm not sure if such a change in the itemRenderer will also change the actual List, though. In theory it should not.
Aside from that, if your Long Press event bubbles up from the itemRenderer, you can listen to it on the List class and change the selectedItem that way, before popping up your new menu.
I'm working on a simple auto complete function for my Flex mobile app. For that I've got a CalloutButton that triggers a Callout.
The Callout holds some lists from which the user can select items. On item select, the callout gets closed (calloutButton.closeDropDown()).
The very same behavior is done for a TextInput. The user inputs text, the callout opens and according to the entered text, the lists change. Works fine so far. Now, when the user selects an item from any of the lists, the callout closes. Also fine.
Now the issue, after the callout is closed, the TextInput automatically regains focus.
On a mobile device this is more than disturbing.
I narrowed this behavior down to the mobile TextInput skin (spark.skins.mobile.TextInputSkin) since a TextInput without this skin class doesn't show this behavior.
Now you might say just use the default skin instead but unfortunately I can't. The default skin has a bug with Android devices that doesn't pass though the enter event. That I could live with since I'n not necessarily dependent on the enter event, however, the spark mobile skin allows be to continue entering text in the TextInput even after the callout has been opened, which is desperately needed as the lists change according to the entered text.
I can't provide any code as the problem has been narrowed down to the skinClass, thus should not be in my own code. Believe me, I tried every nice and not so nice method to prevent the TextInput from getting focus again, but nothing worked.
So, totally stuck here!
Hopefully you guys have some ideas on how to solve this.
Edit:
Below the steps of my application's behaviour. (to be fair, the workflow inside the callout is a little more complex, I'm working with several lists and a SplitViewNavigator here (thus can't use the Flextras autocomplete), but that doesn't affect the TextInput focus issue I'm facing).
Enter text in TextInput
On key change a Callout with two Lists is opened.
The first List receives results according to the entered text from a webservice
User selects item from list
Second list receives results according to selection from first list from webservice
User selects item on second list
Callout closes
This all works fine, except that the TextInput receives focus after the Callout closes.
I really don't know what triggers this behavior.
Edit2: Code to further illustrate the issue.
Naturally, this is stripped down to the very basics, but it mirrors the behavior of the component and focus.
First the CalloutButton and TextInput that can both control the Callout:
<ui:SearchCallout id="detailSearch"/>
<s:TextInput id="searchInput" skinClass="spark.skins.mobile.TextInputSkin"
enter="historySearch(searchInput.text)"
focusOut="searchFocusOutEvent(event)"
focusIn="searchFocusInEvent(event)"/>
The TextInput's focus handlers don't do anything related to the callout, they just set current states of another component, so I'll leave them out here.
Function historySearch closes the CallOut (I forced it to close as it wouldn't close with the usual closeDropDown()), formats the search text, handles a searchHistory and eventually triggers the search function that passes the formatted search text to the selected component.
Here are the parts that matter for this case:
private function historySearch(val:String):void {
detailSearch.forceClose=true;
detailSearch.closeDropDown();
searchEvent(_searchSyms, true);
}
Note: 'val' (the TextInput's text) is trimmed and whatnot, eventually it will result in an array of strings, represented by '_searchSyms'.
Further eventListeners are as follows:
searchInput.addEventListener(KeyboardEvent.KEY_DOWN, onKeyEvent);
searchInput.addEventListener(FlexEvent.VALUE_COMMIT, onKeyEvent);
searchInput.addEventListener(TextOperationEvent.CHANGE, onTextChange);
KEY_DOWN and VALUE_COMMIT don't have anything to do with the Callout, they are used to handle stuff for the searchHistory, hence I'll leave the onKeyEvent function out here.
onTextChange triggers the string search on the server and closes the Callout in case the TextInput's text is an empty string:
private function onTextChange(event:Event):void {
if(searchInput.text=="") {
if(detailSearch.isDropDownOpen) {
(detailSearch.rightView.activeView as RightView).clearDetailList();
detailSearch.isCloseable=true;
}
}
_searchManager.getRicsByChar(searchInput.text);
}
Eventually the server will respond and passes an array of responses. The Callout gets opened and it's lists are filled with the responses.
I won't paste all the Callout content's code here as it would be way too much. Basically, the user selects an item from any of the lists, the Callout is forced to close and the search function that passes the value to the component (not yet pasted here, be patient ;), is given the item's value. That basically looks like this (never mind the FlexGlobals stuff, this gets all refactored once the focus issue has been resolved):
var search:String = String(event.currentTarget.selectedItem);
FlexGlobals.topLevelApplication.detailSearch.forceClose=true;
FlexGlobals.topLevelApplication.detailSearch.closeDropDown();
FlexGlobals.topLevelApplication.searchEvent(new Array(search), true);
Allright, now the final step of the whole functionality, the searchEvent. As already said, this function basically only passes the formatted search value to the selected component. This either happened on 'Enter' of the TextInput (as the code above shows), or on selection of an item from one of the Callout's lists.
public function searchEvent(_searchSymbols:Array, setText:Boolean):void {
if(setText) {
var _searchString:String="";
for each (var _sym:String in _searchSymbols) {
_searchString += _sym + ", ";
}
searchInput.text = _searchString.substring(0, _searchString.length-2);
}
stage.focus=null;
if(selectedWindowContainer) {
// set the array of search items to the selected component here
selectedWindowContainer.setFocus();
} else
trace("[MAIN] no component selected");
}
And that is basically it. This function is the last step of my search routine, and the selected component (that will get the search items), is getting the focus.
Yet, it automatically loses focus again and the TextInput will receive it. I have no idea where and why this happens, and I need to get rid of this behavior asap!
Wow, what a post, anyone still reading this? ;) Well, I hope so.
Well, after hours of testing several ways to prevent the TextInput from automatically gaining focus, I (kinda) solved the issue, although I think it's more a dirty hack than anything else.
Setting the TextInput's focusEnabled to false works fine, even though the focus indication (border around the TextInput) won't work with this any more (an issue I can live with for now).
Still, I'd really like to know what exactly is going on here, especially in the mobile skin class.