Friends,
Assuming a list of items, using Item.index gives the current index of the selected item in a repeater. What is the method to store the previous index?
Thanks!
-Mani B
I would throw item.index into a global variable and then clear it when you’re done with it
Could you please demonstrate it? Also, are there any other ways to do it without using a global variable? Thanks!
Can you tell me what you’re trying to accomplish? I can show how to Set Variable Value in a click action or Set Text but that’s pretty trivial and probably covered in the docs so I think more context would be helpful.
Let’s assume the concept of read vs unread emails in an inbox. Both of these emails are presented in different visual styles of their own when they are not selected. When an unread email is clicked/selected it takes a different style (which is easy enough to achieve using a repeater). However, when the different email is clicked upon, the styling of the email which was earlier selected needs to change (i.e. from unread to read). If you could help with how to target that list element in the Repeater that’d be good. Also, I cannot move away from the concept of the Repeater for many reasons. Thanks!
I have a prototype demonstrating this. Plus a use case where we’d need to save an index in a variable (and alt-version without a global variable).
Demo | inbox selected and readstate.rp (208.6 KB)
1 Like
Thank you so much for taking the time for doing this! I’m not able to open this file in RP 9 as it is made using RP 10. That is the reason I posed this in the RP 9 thread.
Also, looking at the demo I noticed that the inbox icon changes from unread to read on clicking the email. However, the behaviour I was trying to accomplish was that it should change from read to unread only when a different email is clicked which is exactly why I wanted to track the previous index (of the email that was selected). I hope that makes sense. Thanks again!
I was totally not paying attention to what forum I was in! I still got RP 9 installed so I whipped up the demo again in there. these last two repeaters should work and for the life of me, I cannot figure out why they won’t work (not in RP10 either) but maybe they’re a good starting point.
@BenHoang_Axure, do you have any idea why this isn’t working?
On Row click, I’m trying to:
- check if there already a LastSelectedIndex saved
- if yes, update the row data to set Item.ReadState to a certain value where Item.Index == LastSelectedIndex
- select the row
- save a new value in LastSelectedIndex
Demo | inbox selected and readstate-rp9.rp (93.4 KB)
Ah, it looks like you’re running into some nuanced settings of repeaters as well as getting some expressions mixed up. To briefly recap, the second repeater is triggering all of the read icons; And the third repeater isn’t opening those icons at all. To explain why, I’ll list some of the explanations below:
-
The second repeater has the expression [[Item.Index == LVAR1]] to mark the rows. This will cause the repeater logic to consider it like “if this expression is true, mark this repeater as a whole”. We will need to change the beginning of this expression to use “TargetItem.Index” instead. The repeater logic will then be “if this expression is true, only mark this row of the repeater”.
-
We’ll also need to apply the “TargetItem.Index” change to the third repeater as well
-
After looking at the third repeater, it might have been a silly copy and paste mistake but some of these expressions are looking at the LVAR1 widget instead of the global variable “LastSelectedIndex”. After repointing the conditional logic and expression, it should work as intended.
I’ve attached these edits in the .rp file here: inbox selected and readstate-rp9 - Axure Edit.rp (92.1 KB)
I’ve also made further edits about a few other things I am curious about to the third repeater.
-
Like why you decided to include the Header group inside of the repeater and use an interaction to show and place them, instead of leaving these widgets externally and without needing an interaction since they don’t need to be repeated.
-
And why you need to mark and unmark the rows instead of incorporating this expression directly inside of the “Update Rows” rule
To also briefly summarize how to achieve the behavior @mbaluchamy asked in the beginning, you just need to take the Item.Index and store the value somewhere to use later.
You can store this value inside of an existing widget, on a global variable, inside the repeater dataset, or anywhere you please! 
So when you click on a different email, have these values recalled so we know the “last email” that was clicked.
This works as expected. @bamorris and @BenHoang_Axure Thank you both for taking the time to do this for me. I hope the community benefits from this as well!
2 Likes
It’s worth noting that whilst the value of Item.index as a value can be stored in any place, the exact moment at which you can store it can not be at any time you please.
Here’s an old example that shows how the same “Item.index recording” code for an event, will work properly when executed in one context, but doesn’t parse [[Item.index]] properly when executed in another context, because the repeater database is not available at that time.
It’s an interesting example of some of the weirdness that us Axure developers encounter from time-to-time.
Broken Listener.rp (52.5 KB)
Actually, that strategy is a fragile one, because the moment you need the prototype to add or delete repeater rows you will have to add some tricky and error-prone code to figure out how those operations will affect the [[Item.index]] value that you stored earlier.
A much better stragegy is to have an invisible repeater column called (e.g.) “Selected” and set it to true / false as appropriate. That way, the information is not invalidated by the addition or deletion of rows.
1 Like
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.