This is a good example of the “How do I get data from a specific repeater row?” problem. …With an interesting twist of then updating that repeater row if that data is null. The classic way to handle this problem is with the “listener method” (well documented on this forum). You “ping” a widget in the repeater which “listens” to this ping and reports back if it is the correct row. It works like this:
-
Set a “target flag” to define which row you want.
a. This can be a global variable or the text value of any widget.
b. For example, if you want row 3 you could set OnLoadVariable to “3”. (But in your prototype you’ve already set the “selectedslot” variable to a number, so this is already done.)
-
Trigger an otherwise unused event of a widget in the repeater. This is the “ping.”
a. Moved or Rotated are commonly used for this.
b. This must be done outside the repeater so it will be triggered for each and every row.
c. For example, if you have an interaction of “Move ++NumSlot by (0, 0)” then the widget named ++NumSlot will be “moved” (by zero pixels, so no actual movement) meaning its Moved event will be called for the ++NumSlot widget in every row.
-
Add a case to this “trigger event” to test a value in this row against the target flag. This is how the row “listens for the ping.”
a. If it is a “target row”, return the data from this row (or whatever actions you need) typically by setting the value of global variables or text values for widgets.
b. All other “non-target” rows will fail this test, so they will essentially ignore the ping.
c. For example, ++NumSlot would have a Moved event with case logic like, “If [[Item.numslot]] equals selectedslot and my columns are not empty, show the warning message, else if empty, update this row.”
So, in your InputTable repeater, the button first needs to ping the row matching ++inputSlot, by moving the corresponding ++NumSlot widget in the AllocTable repeater. Then, ++NumSlot needs to test if it is the requested slot and if the ““handler”” or "“colli” columns already have data, show the warning message, otherwise if it is the requested slot, trigger the row update. Since you have already stored the necessary data in global variables, ++NumSlot could directly update its own row. However, you’ve created another possibility that needs to be handled: If the row is non-empty it shows the warning message and the warning message has a “Yes” button to confirm the row should be updated.
I thought it would be interesting to try a kind of “double listener method” to solve this. The BUTTON widget in InputTable pings ++NumSlot in AllocTable, then if ready for an update, ++NumSlot pings BUTTON to signal it can update this row. Likewise, the “Yes” button in the warning message can ping BUTTON (by moving it) to force the update.
Here is an updated file:
example2.rp (150.1 KB)
- BUTTON has a Click or Tap event with one action:
Fire Event ++NumSlot fire Moved
I prefer this to Move ++NumSlot by (0, 0) because it makes it more obvious that it is a special thing and ++NumSlot will not actually be moved anywhere.
- BUTTON also has a Moved event that updates AllocTable (if it is the same button in the same row that was originally clicked.)
- ++NumSlot has a Moved event with two cases.
- To test if it is the correct row and its data columns are not empty, I had to use some fairly tricky logic:
If [[Item.NumSlot]] equals value of selectedslot and
[[Item.handler == '' && Item.colli == '']] equals false
Show warning message
- The second case fires the Move event of BUTTON to ping it back and update the row.
