This is a migrated thread and some comments may be shown as answers.

layoutChange called too many times

5 Answers 71 Views
Splitter
This is a migrated thread and some comments may be shown as answers.
Ryan
Top achievements
Rank 1
Ryan asked on 06 Aug 2013, 06:51 PM
I have a page with 4 splitters. I only want to receive a layoutChange event for a particular splitter. When I resize the window the layoutChange callback is executed 6 times. Within my callback I need to calculate the height of a pane (the height is auto and cannot be pulled from the splitter reference as far as I know). Height calculation is an expensive operation and there is noticeable delay when this happens 6 times in a row. I would prefer to avoid creating a counter and relying on a condition such as if modulus 6 equals 0, calculate height.

I've created the following fiddle to demonstrate my issue: http://jsfiddle.net/kUvLZ/.

  1. Is there a better way to bind my callback that will reduce the number of callback executions?
  2. I don't exactly understand how/why the layoutChange is being triggered like this. Helping me understand it more would probably answer the following related questions
  3. I understand that the child splitter is probably listening to parent splitter resizes. But why 6 times? Why not 3 or 4?
  4. Is there a problem with the splitter control that's causing it to fire this many times? I would expect a parent splitter (.references-wrap in my example) to receive all of the layoutChange events from children. I don't expect a child to have to listen to all of the layoutChanges above it.
  5. Could an alternate bind event be created to make it so that layoutChange listens to all nested calls whereas something like paneLayoutChange would only be triggered once?
Help appreciated.

5 Answers, 1 is accepted

Sort by
0
Alex Gyoshev
Telerik team
answered on 07 Aug 2013, 10:00 AM
Hello Ryan!

This is a bug in the splitter -- each splitter is bound to the window resize event, even if it has a parent splitter and is bound to its resize. The result is that each splitter triggers a resize when the window is resized, which accumulates in the resizes of the innermost one.

This has been fixed for the next internal build, so the number of layout changes will drop.

> Is there a problem with the splitter control that's causing it to fire this many times? I would expect a parent splitter (.references-wrap in my example) to receive all of the layoutChange events from children. I don't expect a child to have to listen to all of the layoutChanges above it.

It is the other way around. A nested splitter listens to the resize of its parent, because it may have to recalculate its size. The parent splitter does not care if the nested splitter is being resized, because it will use only its available space and not cause a change in its container size.

All the best,
Alex Gyoshev
Telerik
Join us on our journey to create the world's most complete HTML 5 UI Framework - download Kendo UI now!
0
Ryan
Top achievements
Rank 1
answered on 07 Aug 2013, 11:54 AM
Ah, great. Thanks Alex. I assume the internal build with this fix isn't available yet as the version notes don't mention it. I'll keep checking.
0
Alex Gyoshev
Telerik team
answered on 07 Aug 2013, 03:07 PM
Hello Ryan,

Indeed, the build is not live yet -- I will follow up in this thread once we have published it (by the end of the week).

Regards,
Alex Gyoshev
Telerik
Join us on our journey to create the world's most complete HTML 5 UI Framework - download Kendo UI now!
0
Alex Gyoshev
Telerik team
answered on 08 Aug 2013, 03:44 PM
Hello Ryan,

A new internal build is available for download. Please let me know if it remedies the problem.

Regards,
Alex Gyoshev
Telerik
Join us on our journey to create the world's most complete HTML 5 UI Framework - download Kendo UI now!
0
Ryan
Top achievements
Rank 1
answered on 13 Aug 2013, 12:28 PM
Hi Alex,

The internal build fixes the problem. In my project layoutChange is only called twice now as opposed to the 14 times it was previously. Much better!
Tags
Splitter
Asked by
Ryan
Top achievements
Rank 1
Answers by
Alex Gyoshev
Telerik team
Ryan
Top achievements
Rank 1
Share this question
or