I have the strange problem, that my f7-ranges are not working as expected. I use them in the dual configuration where min and max are item states. In the designer all ranges are drawn as expected, but on every regular page the ranges are not visible. I’ve already checked the item states and they seem to be correct (set to label on same page). When I change the min / max values to hardcoded numbers the ranges are drawn again.
I’ve read in an old thread (Dual range slider - #9 by hmerk) that hmerk faced a similar problem but it just disappeared. Does anyone else had this problem before and solved it somehow?
I cannot replicate your problem. f7-ranges work as expected. In the thread you link to the problem disappeared when other widgets on the page were reconfigured which indicates that maybe the problem was not in the f7-range to begin with. To track down your particular issue, you’re going to have to give more details. What version of OH are you on? What’s the widget code? What’s the page code?
One strange addition I just recognized. Changing the OH pages and designer view etc for the code snippets, I just saw the range bars on the page on one of my browser tabs. Refreshing the page and they are gone again.
I can add another observation.
If the page is used as home page and I click on the OH logo, the bars are visible. Refresh and they are gone. Second if I navigate to the same page via http://myserver:8080/page/mypage, the bars are are never visible.
One difference I found is, that if drawn, the divs with class range-active-bar have a style with left and width set, otherwise the class style sets left to zero and width doesn’t exist.
More complex test:
Add label cards to a different page for OneCallAPIweatherandforecast_ForecastDay1_Maxtemperature and OneCallAPIweatherandforecast_ForecastDay1_Mintemperature. Navigate to that page and then without a refresh navigate to the page that has this widget.
Drat. But at least that gave enough information for me to finally be able to replicate the issue myself. My previous hypothesis was mostly correct, but the workaround has to be a little more direct. Add
The first time the repeater’s loop runs, the states of items referenced in the widget are not actually tracked yet so the f7-range gets undefined values for it’s min and max properties which means the library draws it as having 0 length. In 99% of cases, users don’t notice this issue with the repeater because as soon as the item states catch up, it is redrawn and everything is rendered correctly. In this case, however, there seems to be an issue with the way the f7-library is handling the updated min and max values and it requires a forced full redraw using the key property to cause it to recalculate the max and min with the correct values.
Your explanation sounds plausible, but unfortunately the change hasn’t helped yet. I’m confused that it worked for you but not for me. Could I have done something else wrong?
That’s strange. It doesn’t look like you’ve done anything wrong. Other than the fact that I have to change the item names because I don’t have those forecast items, that code you’ve posted is the same as my test version which does not have the problem. I’m on a 5.0 snapshot, not 4.3.3, but the neither the repeater nor the f7-range has changed between those versions.
When you reload the page are you reloading (Ctrl + r) or hard reloading (Ctrl + Shift + r)? If you are just doing the regular reload, try the hard reload, or even better, long press on the reload button on the menu bar until you get the “Empty Cache and Hard Reload” option.
If that doesn’t work, then you’ve got some extra ghost in the machine…I suppose you could try an OH restart as well.
But, if it were me, I would find it faster to build another solution than try and trace down whatever obscure cache problem is causing this. Because you are not using the actual interaction feature of the range bar, you are really just creating one transparent div with a second smaller colored div inside. Getting that pair of divs to look just like the f7 range would be the matter of looking at the actual f7 range elements and adding the correct classes (probably just some combination of range-slider, range-bar, and range-bar-active, but there may be a few others as well. The only tricky part is that you’d have to do the calculations for the width of the colored bar yourself based on the items, but this could be streamlined with an oh-context.
I think that will be the way I’m going to take. Do you know any good/complete oh-context examples? I tried a few times to use variables, but they never worked for me.
Either way, thank you very much for your effort and your help!
In this case you don’t want variables, you want functions which greatly simplifies the expression when reusing some more complex calculations. For this you probably want something like this:
- component: oh-context
config:
functions:
leftPos: =(val, min, max) => ( val - min ) / ( max - min ) * 100 + '%'
barWidth: =(upper, lower, min, max) => (upper - lower) / (max - min) * 100 + '%'
slots:
default:
- component: div
config:
style:
border: 1px solid black
width: 100%
height: 10px
position: relative
slots:
default:
- component: div
config:
style:
position: absolute
background: blue
left: =fn.leftPos(60, 50, 100)
width: =fn.barWidth(75,60,50,100)
height: 100%
I finally got around to trying your suggestion and it seems to work. Unfortunately, after changing and saving the code the widget is not editable in the developer view anymore, as the browser freezes right after loadup everytime. But at least the regular page seems to be fine now.
