I’m building a predictive search interaction and trying to figure out how to get Axure return a specific column’s data within the selected repeater item on hitting ‘Return’. This works fine when I use the mouse to select the item. However, I’m not able to do it using the keyboard as Axure always indexes the TargetItem as opposed to the Item. I found this detail out by firing an onClick event and looking at the data Axure returned.
Getting the value of selected repeater row on hitting 'Return'
josephxbrick
#2
Hi!
Whenever you want to get information about a particular row from outside of the repeater, using the so-called “listener” method is the way to do it. I assume that you want to choose the first result in the repeater upon hitting enter, correct?
The way the listener method works is that you execute a command upon a widget in the repeater row, such as “Move by 0,0” and the widget’s corresponding event (On Moved) will be triggered for each row in the repeater, and you can use a condition on that event to find out information about the current repeater row using the “Item” object. (If you google “axure repeater listener” you will see many forum posts describing how it can be used an how it works.
Anyhow, when the field senses the enter key being pressed, you want to move a widget in the repeater. (You can use the same widget in the repeater that gets clicked.) E.g,
On Key Up (of field)
if text on this not blank
Move (rectangle search result in repeter) by 0,0
Then, add the following event to the rectangle that gets moved
On Moved (of widget in repeater)
If (value) [[Item.isFirst]] equals true
Set text on search field to [[Item.columnName]] -- (this is the column containing the searched for text)
hide repeater
I’m attaching a file. Note that I modified the predictive-search widget in Axure’s stock Sample UI Patterns library.
predictive search return key.rp (51.4 KB)
mbaluchamy
#3
@josesphxbrick I appreciate your response. I had used the repeater listener technique before to find the index of the selected row in order to highlight it when interacted using keyboard. However, accessing the repeater’s data within the selected row is my problem exactly. This listener technique works only when the predictive result set has already been filtered down to one result or if the desired result is isFirst or isLast. Doing an Item.columnName when the result is NOT isFirst or isLast or with more than one result is something I’m having trouble with. Practically speaking, the user shall be able to select any desired row. I’m hoping that this clarifies your assumption too.
asbjorn
#4
Hi. If you can Mark a given row in the repeater (based on unique content), I believe you should be able to pull data for that row from the repeater. It’s just a hunch; I haven’t tried it myself.
josephxbrick
#5
Hi mbaluchamy -
IsFirst is only one of many conditions you can check for. You could use the same technique to find the row with a selected widget.
It’s still not clear to me what you want to happen when you press return. If you’ve typed and winnowed the list down to 4 items, which one do you want to select upon Return?
mbaluchamy
#6
Below is a screen grab from your demo file:
In the above image:
Could you advise me on how you’d program Axure to select “Bonus Extra Part One” or “Bonus Extra Part Two” using the keyboard ( and certainly avoiding hardcoding)?
(Note: The above list is already filtered a subset of a master repeater list which is a perfect scenario mimicking my case)
Thanks much!
josephxbrick
#7
Hi!
This can be accomplished with (surprise) the listener method.
I added a keydown handler to the field, which increments/decrements the “variable” v_focusedRow on up-arrow/down-arrow. (I don’t use global variables if I don’t have; I use labels instead.) A listener in the repeater highlights the row whose Item.index matches v_focused row; this listener is triggered upon hitting the up/down arrows.
There is a second listener (triggered by pressing enter in the field) that updates the field with the row that has “focus.”
Two notes:
- I added a bit of javascript on Page Loaded that prevents Chrome (and other browsers) from displaying its own auto-complete on field inputs, which screws up your interactions.
- Because the filter is updated whenever the text in the field changes, the filter also updates when you set the text by hitting Return, which was causing timing problems. So I added a second variable (defaulting to false) to avoid the filter being updated upon hitting return. (See the added condition on Text Changed.)
Lastly, Axure has a bug with repeaters that sometimes shows the hover style on various rows randomly when also using a selected style (your hover style is dark blue). I may have a workaround if you are seeing that. Worse case you get rid of your hover state.
Let me know if you have any questions or see any bugs.
predictive search return key.rp (56.3 KB)
mbaluchamy
#8
@josephxbrick The technique of using another listener works smooth like icing on a cake. Also, your note on avoiding global variable appropriately and the solution you use is a learning. I shall share my completed file once I’m done. Thanks much for your patience. Glad to have you in this forum!
josephxbrick
#9
The main reason not to use global variables is that you can copy the entire solution from one file to another without first having to remember to create the global variables that the solution relies on. Also you can document it better by putting text next to the variable label it saying what it’s for.
Of course if you have to transfer a value between pages, then a global variable is needed.
mbaluchamy
#10
@josephxbrick Could you help me understand what is the reasoning behind setting the variables to true and later false before and after populating the text field respectively? What exactly happens during those times when the variable values change? Can’t we just set it to false and leave it alone?
josephxbrick
#11
Hi!
The reason is this: the filter is updated on the Text Changed event. That event is not only fired when the user types in the field; it is also triggered when the text of the field is changed through code. Setting this variable to true just before setting the text of the field and to false again after setting its text prevents this filtering from happening, due to the condition I added to the Text Changed event.
Hitting return causes one of the listeners to set the text of the field to the “focused” value, which in turn re-filters the repeater. This was causing a bug, which you will see if you remove the “set to true” command.
I didn’t want to spend the time to debug what exactly was happening, but I figured that reapplying the filter was somehow “short-circuiting” the listener’s trip through all the rows, so I added this code. There is probably a less hacky solution out there, but there is no reason to refilter the repeater here anyhow, since it’s hidden.
system
closed
#12
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.