Only one row with value 'true'

Hi,

is there a nice way to make sure there is only one row with the value true for a column in a repeater?
The others should be false.
This way the application is slowing down from click to click:
image

kind regards

Just to clarify, from a visual perspective, are you currently setting the “Is Selected” of the relevant UI components in the “Item Loaded” of the repeater?

No “IsSelected” is set in the Click handler of a repeater items hot spot
image

Hi!

This works:

On Clicked
  // the following line updates all rows but the current row
  Update rows set isSelected to false where [[TargetItem.index != Item.index]]
  Update rows set isSelected to true for this

Hi again -

I just reread your post, and I realize it was performance you were after, and I’m pretty sure my previous reply would have bad performance.

The goal is to unselect only the selected row (rather than all other rows), then select the current row

Start with all isSelected rows set to false, and create a global var called v_currentSelection, and default it to 0 or just blank (anything but a positive number). Or, if you want, say, the first row to be selected by default, set the row value that way and default the variable to 1.

On Clicked
  If value [[Item.index]] does not equal value of variable v_currentSelection
    Update rows set isSelected to "false" where [[Item.index == v_currentSelection]]
    Set value of variable v_currentSelection to value [[Item.index]]
    Update rows set isSelected to "true" for this
1 Like

Hi,

so this approach has still bad performance as you said.

this approach is working better as long as a only click one after the other in one direction. If I select an item which is before the currently selected, it won’t be selected.

image

ListManagment_SelectedField.rp (716.4 KB)

That wasn’t what I asked.

I can see that you are setting the column in the click - I asked about the UI components which get visually changed in the selected row.

Anyway, the reason I asked is because I find that visual feedback is unacceptably delayed when doing visual updates in Item Loaded, , so I personally make UI updates manually within the click event as well, and then I have a Wait(0) (which spawns a background task for the commands that follow - i.e. the Update Rows etc.) which ensures that the Selected style changes are displayed immediately.

This results in a highly-responsive UI that is unaffected by the size of the repeater. Yes it’s true that the “real work” isn’t complete until half a second later, but that’s the case in all circumstances anyway, and I’d rather have a UI that feels responsive rather than delay the UI visual update till after all the Update Rows stuff completes.

Hope that’s useful info in some way.

Rgds,
Jeremy

Hi!

My bad: change the update rule to [[TargetItem.index == v_currentSelection]]

1 Like

ah now I got you. Thats really good to know. Thank you for your input.
I started using Axure two weeks ago and these hints are very welcome.
For my current application I think I won’t change to your approach, because I assume with the solution everything will work very well.
But for my next prototype I will try it your way.

Great. Thats working. I am still struggling a little with the diefference between Item and TargetItem but as I understand right Item points to the currently interacted object and TargetItem iterates in a way through the repeater. Is that right?

Thank you for you patient help

Yes.

For example, you might have a rule that says [[TargetItem.myColumn == Item.myColumn]] which would mean “all the rows where myColumn is the same as this one”

Rather confusingly, if you make a call to Update Rows (or whatever) from outside a repeater, then Item acts as the iterated item (presumably because “Item” is otherwise meaningless when referred to outside of a repeater).

There are only two situations where it seems important to use TargetItem:

  • When you are updating other rows in a repeater from an interaction within a row of that same repeater
  • When you are updating rows in a different repeater from an interaction within a row of a repeater.

For example, in an Update Rows command executed from outside of the repeater context (e.g., a button not in a repeater), Item works just fine.

BTW: Axure 8 was far more forgiving of using Item and TargetItem interchangeably. In fact, my second post works fine in Axure 8, which I still use as my primary tool, and interestingly, when I opened the Axure 8 file in Axure 9, it made the change for me.

may I increase the difficulty level?
what if I have two repeaters and only one item over these two should be selected and the field isSelected be true.
And how find the selected item from outside the repeaters to update another field?
I would like to have a details area for the selected item to change for example the name.

My first idea is to increase the value for v_currentSelection for the second list by the length of the first list.
Does that make sense? What would be your approach?

Hi!

Unfortunately the repeater has no “lookup” function where you can find a row with a query. However, you can do this with a repeater “listener.” The traditional method is to move by 0,0 a widget in the repeater, which will fire its On Moved message for every row. This On Moved event basically becomes a mini On Item Loaded in that you can use the exact same code you would would use in On Item Loaded: you can access Item.index, Item.columnName, etc.

Note that move command must be executed by a widget outside of the repeater.

So say you have a number field called indexField, and you want to press a button to select a rectangle in the repeater row whose index matches the field value. You would put, say, a hotspot in the repeater row and use the following code:

On Moved (of hotspot in repeater)
  If value [[Item.index]] is equal to text on field indexField
    set selected of rectangle to true

Then the button code outside of the repeater would simply move the hotspot by 0,0 on click.

You may, in your solution, need to trigger a listener in repeater B from inside of repeater A. Since a listener only works if the Move command is executed from outside of the repeater, the trick here is, from inside of repeater A, move by 0,0 a widget that lives outside of both repeaters, which in turn will use its On Moved event to trigger the listener (i.e., move it by 0,0) in repeater B as described above.

Hopefully that’s enough to get you started.

interesting mechanism with that listener.
Unfortunately I cannot make it running.
Could you please help me with my file?

ListManagment_SelectedField.rp (738.4 KB)

  • on click on an item, it moves the helper object outside of the repeaters
  • on moved of the helper object, a hotspot in both repeaters is moved
  • on moved of the hotspots the same code as before is called in both repeaters

Hi!

If I understand the goal, it’s to make the clicked row the only “true” row across two repeaters.

So if row 1 in repeater1 is true, and I click row 3 of repeater2, row 3 of repeater 2 becomes true, and row 1 of repeater1 becomes false. Is that what you want?

If that’s true, then you can simply do an update from one repeater to another, since we already have a “variable” letting us know which row in true for each repeater…

I’m attaching a file that does it that way, as well as one using listeners, which I’d treat just as a listener example.

select_just_one_row.rp (67.8 KB)

1 Like

sorry for my newbe-explanations… I’m glad you understand me :wink:

oh man, easier than expected. Thank you so much for this solution. works like a charm.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.