Support Forum
Search found 62 matches
Component Version: @bryntum/gantt": "5.1.1", "@bryntum/gantt-react": "5.1.1" Chrome Version: 105.0.5195.102, OS[/list] We are using the Gantt component and have added checkboxes to toggle on/off CriticalPath, Baseline, and TaskLabels. If a user doesn't "un-ch...
Hello, For the gantt UI, there is a left grid of tasks and a right grid of the calendar/schedule, and then a divider line that the user can drag left/right to move the schedule region larger/smaller. Is there a way to programatically trigger actions of the the "click > to close" and "...
Nevermind, this works:
* calculateTotalSlack() {
return 0;
}The [code] syntax is continually screwing up the formatting of my post, and I'm going to stop trying to fix it, because it keeps breaking it. Hopefully you get the idea.
I'm trying to override total slack (and hence critical path) with our own backend calculation, but having trouble with the right generator incantation. For this demo page: https://bryntum.com/examples/gantt/criticalpaths/ I'm changing Task to look like: class Task extends TaskModel { get cls() { // ...
Oddly enough, we used to set criticalPaths: { disabled: false } ... if we remove that, but use task.critical for our own critical path styling, the performance issue goes away. This seems really weird...like TaskModel.critical is being correctly & quickly calculated (even though we now have the ...
Hi Alex,
I see it is possible to turn off the criticalPaths via the feature flag. Can we use our own logic for this instead somehow? I tried setting TaskModel.critical, but that appears to be only a calculated value. Is there any other way we can set whether a Task is part of the critical path?
Another data point, keeping "on Fri at 23:59" but removing this-and-only-this task from the data JSON string in our repro story avoids triggering the issue: {"displayId":21,"id":"t:107406","startDate":"2020-10-30","duration":7,&qu...
More intrigue: "on Fri at 23:58" works just fine, same as "on Sat at 0:00", which is great for us, we'll just use "23:58" for now.
But that seems really strange that specifically 23:59 is what triggers the bad behavior.