Our state of the art Gantt chart


Post by rapiduser »

saki wrote: Fri Nov 12, 2021 6:08 pm

Do you really need to react to tick size change? You can get the current tick size whenever it is needed. Ideally you should not use undocumented events – they can change or be removed without warning.

What is the use-case? What would you need to do in the listener? Maybe there is a solution w/o using undocumented event.

The use case is I need to create presets for zooming and the tickWidths for each preset should either increase (zooming in) or decrease (zooming out) and it should be based on the actual tick width/size of the preset. Since the width can change as you had explained I need to get the calculated width and create the presets from that value.

I do have a reference to the gantt ref and it does have a tickSize however its not the correct value that I see in the UI. Its smaller. It looks like there are multiple rendering phases and tickSize from the gantt does not get the latest calculated tickSize that's based on the view port. Perhaps this is because the size is dynamically adjusted and something is done internally..unless I am doing something wrong

Using the timeaxisviewmodelupdate event and getting the tickSize from the gantt instance that way gets me the correct tick size that is seen and rendered in the UI.

I tried using the timeAxisChange event but it does not get the up to date tickSize. It's always a size behind. If I set the tickWidth to 150 and the library dynamically adjusts the tickSize to fit the view port to lets say 500 it returns 150. If I change the preset to a new tickWidth of say 300 by zooming and get the tickSize in the timeAxisChange listener it will return 500 (which is the previous tickSize) so its not up to date and instead returns the last tickSize changed explicitly.

Does that make sense?


Post by rapiduser »

I think I can leverage the update event for the TimeAxisViewModel. It's not internal

Unless there is a more efficient solution that you could provide for my requirements?


Post by Maxim Gorkovsky »

Hello.
It appears to me that you do not even need default zooming behavior because it differs too much from your vision. I would recommend to override public zoom methods (zoomIn, zoomOut, zoomToLevel, zoomToSpan, etc see this doc: https://bryntum.com/docs/scheduler/api/Scheduler/view/mixin/TimelineZoomable).
zoomIn/Out/ToLevel just go over the configured presets, pick next/previous and calculate optimal date range for it. Those methods are called when you try to Ctrl + mouse wheel on the scheduler or change zoom level with a slider. In your implementation you can do whatever you want and you do not need to generate presets every time. For example:

zoomIn() {
// this will set new view preset and set new time span
  this.viewPreset = {
    base : 'weekAndDay',
    tickSize : 100,
    startDate : ...,
    endDate : ...
  }
}

Originally you were concerned about tick size not matching config value, but that should only happen if configured time span with a configured tick size does not take all available space. If it does - your tick size will be exactly what you configured it to be.


Post Reply