Can't align OnClick hotspot in variable height Repeater

repeater-widget
#1

I have a repeater that contains text of variable length in a fixed width field, so the text will run on to a variable number of lines.

I’ve developed an algorithm based on average character width (pixels) and no. of chars per line that allows me to offset each entry by an amount that takes into account the aggregate heights of the previous entries. So far so good (although it would be nice if there was a simpler way to do this.

However, I have also assigned OnClick events to these elements but the resulting OnClick ‘hotspot’ areas are out of alignment with their corresponding shapes. Some hotspots don’t even work. It looks like the hotspot area doesn’t take any notice of my offset algorithm.

In the attached example, click on any user names or text areas to see which one do/don’t work and the underlying hotspot shape.
20160329 Axure Example.rp (222 KB)

Bug: Repeater doesn't fit to wrapped text after repeater action
#2

Hi fastnbulbous,

Hmm, it looks like this file may be pushing the limits of what repeaters in 7.0 can do. One thing that’s new in 8.0 that looks like helps is the “Fit to Content in HTML” option for repeaters since this allows each repeater row to resize to fit the amount of content that is currently shown in that row (similar to how dynamic panels can fit to content). I tried opening up your file in 8.0 and turning on that “Fit to Content in HTML” option for the “Thread Text” repeater and it looks like that allowed each repeater row to resize to fit its content without moving away from the clickable area.

Hopefully that works for you too!

#3

Thanks Alyssa

I’ve installed 8.0 and tried this and the answer is: yes and no! I stripped out all extraneous code and shapes so I am just populating the ThreadsText element in OnItemLoad. The only other action is a sort in the OnLoad.

You’ll see that it’s all in an odd order (I added a sequence number to each element in the repeater so you can see the ‘random’ order), overlaps and the clickable area doesn’t hold up.

However, if you delete the sort from the OnLoad action and re-publish, it all looks fine and the clickable area is OK too - it’s just not in the order I want!

Looks like the sort is screwing something up?

20160402 Axure Example.rp (244 KB)

#4

Hello again Alyssa!

I’ve taken this a bit further. I’ve added a couple more shapes to populate from the repeater and left out the sort that was causing a problem (see previous post). In order to see more clearly how the resizing and positioning was working I added frames to all three shapes.

When you publish, the spacing and clickable areas are OK, but the rectangle frames remain at their original size - in other words the frame does not resize to match the shape.

Also, if a shape above another is resized (see the 2nd UserID shape that has a long string of 5s) it doesn’t ‘push’ those below so we start to get the upper shape overlapping with the lower.

See attached file.
20160402-2 Axure Example.rp (230 KB)

#5

Another step, but not really forward!

I’ve added three buttons:
[ol]
[li]TOGGLE SORT. This sort on timestamp alternating ascend/descend.[/li][li]FILTER. This applies ThreadsUserID = 1.[/li][li]RESET. This removes both the sort and filter.[/li][/ol]

The problem is that using any of these upsets the variable height layout. In fact, clicking the RESET button without having clicked either of the other two first also screws it up!

It appears that variable heights works when simply loading the repeater, but if you actually want to DO anything with it…

Handling variable heights is important for a lot of applications but with these apparent limitations in the beta I’m not sure how much use the current implementation will be!
20160402-3 Axure Example.rp (241 KB)

#6

Hey fastnbulbous,

Sorry for that long delay (I’ve been in and out of the forums this week)! I took a look at the sample file and tried creating my own test file, and I do in fact see that repeaters seem to lose their “Fit to Content” height after they have been modified. I hadn’t noticed this before but this does seem buggy to me so I’m going to go ahead and file it as a bug. Thank you for taking the time to write out your findings and post those files!

#7

Thanks Alyssa.

Is this likely to be fixed for first release do you think?

#8

hi alyssa, there is an other bug, propably related.

if you have a autoheight repeater it also breaks if you are setting text of a widget to a “dynamic” value. i tried with this.y (rectangle inside the repeater).
it breaks both if you are targeting a widget inside or outside the repeater.

#9

Hmm, I don’t have an estimated timeline for the fix so I can’t say for certain if it will be fixed in the first official release build, but it looks like it may be one of the ones that we’re going to try to get fixed sooner. I would keep an eye on the change logs for each new build to see whether this particular bug gets fixed in that build.

Hey Gregor,

I tried reproducing the issue on my end and wanted to confirm the behavior that you’re seeing. I’m assuming that your repeater has text of varying lengths, which makes the repeater rows each load with different heights. Then, when you click on one of them to set the text on that rectangle to [[This.y]], the text changes but the row height doesn’t–is that right? If that’s so, then I think the reason that the repeater rows aren’t resizing to fit the text when the “Set Text” action fires is because changing the text doesn’t redraw the repeater. That said, updating/redrawing the repeater still breaks the “Fit to Height in HTML” function so you wind up getting the same result as the bug filed above. I’ll add this as a note on the bug that I filed. :slight_smile: Thanks!

#10

no. it does also happen if i set the text with [[LVAR1.y]] if the target shape is outside the repeater.
Untitled2.rp (57.9 KB)

#11

Aha, thanks for attaching that file! That is indeed different from what I was seeing before with the OnClick. This does look related to the previous Fit to Content in HTML bug so I’ll get this filed together with the first one. Thank you for bringing this one to our attention! :thumbup:

#12

Alyssa - as a relevant newby, would you mind ‘thanking’ my input if you think it merits?

#13

Hey fastnbulbous,

If you’re looking to accumulate “thanks” to boost the little green bar above your profile picture then we’d recommend keeping an eye out for posts from other users who have questions. Answering questions for other forum users or posting tips, tricks, and resources that are helpful to others (like widget libraries) is typically how one would get those “thanks”. :thumbup:

#14

Any new fix for this yet? There’s been no update for almost 2 years (unless I’m not finding it…)

#15

Hi! It doesn’t look like this has been fixed, but I’ll update the filed report on our end. We’ll make sure to update when there’s news!