Broken Repeater Listener Puzzle


#1

Anyone know why this ridiculously simple repeater listener is not working?

  • Clicking the button fires the Move event (listener) on the repeater item
  • It correctly sets the item.index monitor to item.index
  • It also sets a global to item.index - but this fails
  • Global variable contains the literal text “[[item.index]]” not the value
  • If statement also cannot access item.index

Starting point:

After firing the listener:

As you can see - the global variable LITERALLY contains the text “[[item.index]]” which is remarkable because assigning the exact same expression to the text box results in “2”.

If Set Text can access [[item.index]] properly, how come nothing else in this listener can?

Rgds,
Jeremy.

Broken Listener.rp (51.4 KB)


#3

I cannot tell you why Item.index is not available when setting the variable (it is also NaN while setting a label), but in your case you could set your variable to Item.column0. This works. I hope this helps.


#4

Hi, JMW. I struggled with something like this recently, too. Check the attached. The only change I made was the addition of the button that actually moves the item instead of firing the Moved event.

Broken Listener.rp (52.5 KB)

An explanation I got from support is that the interaction outside of the repeater doesn’t have access to the repeater database, which is required to get at the index value. By actually moving the widget you’re getting an event to fire inside the repeater, and it works. This difference in behavior suggests that the “fire event” action doesn’t do literally that–maybe it just performs the actions attached to that event, correcting for “this” and “target” references–but whatever the difference it doesn’t seem to matter except in a few situations like this.

I’m thinking that going forward I may just put a text field in the repeater item as a listener and then put all the logic on the Text Changed event. That way I can set the text to any number of different commands and the single widget can listen for all of them.

HTH,
Jeff


#5

Ha! - d’you know Jeff, I had considered exactly this maybe a half-dozen times! Each time however, a little voice inside my brain said “Nah, don’t be dumb, of course they’re exactly the same thing!”

Interesting how Set Text still works though.

I was also going to start using the Text Changed event in the manner you describe - hence my question a few days’ ago regarding how to fire Text Changed from javascript - it was so that I could get JS to issue any number of commands back to my prototype.

But I had a bit of an epiphany two days ago:

  • Most people are familiar with using hidden, carefully-named widgets to act as local variables
  • Why not use hidden, carefully-named buttons to act as custom-named functions?
  • All you need do then, is to fire Click from other widgets when you want to activate the named function

Well as it turns out this works spectacularly well. It essentially forces you to create a “Debug UI” for your prototype. All the “variables” can be on display as you run it, and you have buttons to manually test every custom function you’ve written - works like a charm. You can even group the controls and make them visible/invisible based on the status of a global variable called “debug” or somesuch.

Nonetheless, for any proto I do in future with non-trivial data structures, I’m going to write the data engine in JavaScript. Last week a fairly simple array-like construct which took me hours to simulate and debug in Axure, was re-written in a matter of minutes using Axure’s javascript ‘back-door’.

There is a point at which the point-and-click code-builder and associated function editors within Axure start to seriously slow down prototype development.

Thanks everyone as always for your help on this (and other) matters.

Rgds,
Jeremy.


#6

Yes I think this is why I’ve survived with Fire Move in some previous prototypes without issue.


#7

If you were able to share this I would be super-interested in seeing it. My JavaScript skills extend only as far as modifying stuff that already exists.

J


#8

Sure - I’ve added it as a new topic, so it’s easy for people to find in future.

Best rgds,
Jeremy.


#9

It occurred to me that maybe you’ll find this relevant, or at least entertaining. Here’s a flow chart from a recent project in which I had three repeaters that needed to be in sync while allowing the user to add/delete/duplicate members of any of them. (The data in the three repeaters represented three levels of hierarchy, so a duplication of an item at the top level meant copying the relevant rows in the other two, etc. It got hairy.)

image

Here’s a detail:

image

The blue boxes just outline what’s going on, but the orange dotted outlines are the widgets that contain functions. So, the OnClick event of the orange box in creates a new profile ID (and puts it in that text box), adds the new profile item, etc. As you suggest, this lets you actually click on those components to test a part of the logic in isolation.

I incorporated as much of the logic as I could into this chart, but of course sometimes you need to trigger something to happen inside the repeater item. The little person icon next to the blue shape indicates that–all three repeaters have one of these little dudes hidden in there:

image

This little “elf” inside the repeater is where all those are kept, on various events.

Jeff