search envelope-o feed check
Home Unanswered Active Tags New Question
user comment-o

scrollToResource is buggy.

Asked by Ryan
2 months ago.

I am trying to use scrollToResource() on a scheduler that has 250 resources.

Some page-loads it works great, and continues to work until the page is reloaded again.

Both primary Resources (Room Type) and children (Room #’s) work as expected.

…but more than 50% of page reloads, it will not work right.

When selecting a Room Type or Room #, it scrolls to the very bottom for a fraction of a second, and then it scrolls to about 1/4th down the list. It does this no matter which Room # or Room Type you choose.

Here is the onchange() code for the select drop-downs:

dpRooms.scrollToResource(this.value); this.value=0;

…that’s it.

If I reload, try, reload, try, reload, try… it will work perfect about 1/3 the time, and be broken the other 2/3’s.

Thanks for anything you can recommend to try to fix it (most of not all the time).

Answer posted by Dan Letecky [DayPilot]
2 months ago.

The scrollToResource() method is quite simple (it sets the scrollTop style to the appropriate value) but it is executed asynchronously, after a delay of 100ms. It’s good to take this into account.

I recommend checking if you don’t execute any other update at the same time.

Also, calling this.value = 0; in the onchange event handler might trigger another onchange event.

You can try calling scrollToResource() from a simple button to see if the problem is caused by the onchange logic.

Comment posted by Ryan
2 months ago.

I am still having the issue, even from the console:

Each of those were done full seconds after page load and full seconds between each other.

Each time I did it it got closer to UF1Q.

On the 4th time it was shown but there were a couple rooms above it.

On the 5th time UF1Q was on the top, like it should have been every time.

Once it is right, it will work forever, but a different RoomType might need to be run a few times still.

EF1Q is on the bottom. Each time the scroll-bar indicator on the far right jumped to the bottom for a second, and then jumped way back up, but less and less until on the 5th try again.

I just tried doing it 5 times on one line but it took 7 lines to get to the right spot.

Some times, on page-reload, it works perfect. Still about 1/3 good, 2/3s bad.

OK, I just noticed when it doesn’t work, the left scroll bar is fat.

I think the right scroll bar is one I added, and the left scroll-bar is yours, or maybe the opposite.

This is really funny… I can use the right scroll-bar, to scroll to the very bottom, and as I do the left one shrinks and goes to the bottom too. The funny part is that if I scroll back up using the right scroll-bar, the left one gets big again. If I scroll down with the left scroll bar, it does not go to the bottom, but when I release the bar, it shrinks and is in the middle. After you go to the bottom 5-times, the left and right are finally in-sync, just like they are sometimes on page-load.

Wow… if you use the right one to go to the bottom, and the drag up using the left one, it also grows, and after that you can’t move it down to the bottom (well, you can if you pause, wait for list extension, and then keep scrolling 5 times).

…so it is not Scroll-To that is buggy, it is the Resource scroll lazy-load magic.

Thanks for any advice you may have.

Here is my double-scroll-bar code:

      //Allow double scroll-bar (and fix issue with doubled-height)
      $('.calendar_transparent_rowheader_scroll').css('overflow-y', 'scroll');
      $('#'+dpName+' > div:nth-child(1) > div.calendar_transparent_rowheader_scroll > div > div:nth-child(1)').css('display', 'none')

Comment posted by Ryan
2 months ago.

Here is a screen-shot that sums up my findings…

Comment posted by Ryan
2 months ago.

Sorry, I may have an answer, kinda…

I think this line is somehow responsible:

$('#dpRooms > div:nth-child(1) > div.calendar_transparent_rowheader_scroll > div > div:nth-child(1)').css('display', 'none');

My comments say it was supposed to “Fix issue with Doubled-Height” that was cause by enabling the 2nd scroll bar. It was so long ago I have no idea. It seems to always load fine now without that line, and if I execute that line in the console, it sometimes makes the left scroll big (weird!).

Ok, I loaded an old dataset, and the resources do indeed have an issue without that line of code.

On a dataset with only 2 resources, you can scroll below those 2 resources (in to emptiness) with the left scroll-bar, even though the normal right one is no scroll-bar at all since it fits on the page.

On a data-set with 2 pages of resources, the left bar is smaller than the right bar, and you can scroll to a 3rd empty page.

In both of those cases running that line of code fixes the issue and all is well.

Now back to my dataset with 210 resources… it works fine without that line of code, and running that line of code, even 10 seconds after page-load can sometimes make the left bar huge and will get smaller as it lazy-loads as you scroll (but other times it will just get a little bigger, and rarely it will stay the same and all is well).

Any ideas on how to fix this, other than adding a flag to enable/disable that line of code per dataset?

Comment posted by Ryan
2 months ago.

NOTE: Even when it is disabled on the big one, there is junk space below the bottom that the left-scroll (I know, I’m not really supposed to enable that, but I like my resource scroll bar a lot, I tried just moving the other one to the left side but it is not as good as just having two).

That line of code 100% fixes things with no issues all the time on small resource lists, and sometimes with no issues on large resource lists. Even when there is an issue of the large scroll bar, I can live with that as it still works fairly well. The one major issue is that it breaks scrollToResource.

Comment posted by Ryan
2 months ago.

No updates? Please help. I really want the resources scroll-bar, with working scrollToResource, and without a bunch of invisible junk on the bottom causing it to scroll past the last item.

Comment posted by Dan Letecky [DayPilot]
2 months ago.

The problem is that you are modifying the CSS in a way that interferes with the built-in functionality. The Scheduler doesn’t support a scrollbar on the resources section. The calculations and the DOM structure are based on the assumption that the scrollbar is not there.

You can still use a mouse wheel on the resources section to scroll everything down but unfortunately the scrollbar isn’t supported at the moment.

Comment posted by Ryan
2 months ago.

Ok, I was just hoping someone could help me “hack” what I am going for.

Having 2 scroll-bars to show you the list-position just to the right of the Resources (in addition to the far-right of the page) make things more user-friendly in my opinion.

Again, you can enable the scroll-bar easily with this line:

$('.calendar_transparent_rowheader_scroll').css('overflow-y', 'scroll');

…the only issue is invisible stuff on the bottom makes the list scroll too far past the last item.

Then, this line fixes that problem:

$('#'+dpName+' > div:nth-child(1) > div.calendar_transparent_rowheader_scroll > div > div:nth-child(1)').css('display', 'none')

…and causes no issues on small resource lists, but for some reason causes a “lazy-load” effect on long resource lists which prevents scrollToResource() from working (unless it is executed 5+ times during which the lazy-load, loads everything).

It is just very strange behavior, and I realize that’s what you can end up with this type of “hack”, but I was hoping someone could help me understand what it is doing better, so that I might be able to find a fix for large Resource lists. Any information I what that line of code is hiding, and why it would make long lists react that way (on some page-loads but not others)?

Better Question: Anyway to disable any sort of lazy-load feature so it can work on every page-load?

Comment posted by Dan Letecky [DayPilot]
2 months ago.

You can try to turn off the progressive row rendering.

To prevent performance issues, it will be necessary to turn off row header width auto-fit. It will still affect performance so it may be necessary to test it.

Answer posted by Ryan
2 months ago.

I greatly appreciate the attempt.

I think setting progressiveRowRendering: false did fix the issue.

Unfortunately:

1) For some reason the top RoomType (EventParent) is blank and no click-to-collapse either. All its Rooms (Event Children) are file below the blank top, and all other RoomTypes except the first one work fine.

2) It is slow for scrolling and there is a couple second delay when expanding/collapsing any RoomType.

Thanks for showing me that though.

I might try going back to an older hack of mine that just moved the right scroll-bar to the left side of the events. It didn’t look quite as good as having a 2nd scroll-bar on the right of the resources, and maintaining the right side of the events… but it might be the best solution.

On the other hand, I guess I am also ok with my current solution, that only hides the blanks at the bottom of the 2nd scrollbar if there are <100 resources, and leave the invisible bottom stuff for 100+ resources… that seems to allow scollToResource to always work, and the extra scroll beyond the bottom of a list of over 100 rows is not that bad.

Anyway, thanks again for allowing me to know that I am kinda breaking progressiveRowRendering when I hide the invisible stuff at the bottom of the resources rows.

This question is more than 1 months old and has been closed. Please create a new question if you have anything to add.