Search found 1704 matches

Hello, If the task's calendar and the resource's calendar do not have any overlap then show it as in case "2b". Is there a way to do this? Theoretically you can change the histogram data before rendering ( this guide has some info on that regard). So you can adjust any tick values. But I t...
Hello, You could try something like this: const histogram = new TimelineHistogram({ ... getRectClass(series, rectConfig, datum) { // If "work" value is less than "travelTime" // reorder the bars if (datum.work < datum.travelTime) { switch (series.id) { case 'travelTime': rectConf...

I'm not aware of any manuallyScheduled field special treatment when applying response.
Could you provide a runnable test case so we could reproduce and investigate the issue?

Hello, Is this expected behavior? If so is there a way to prevent it? Yes this is by design. Events are scheduled ASAP and start/end dates are calculated fields. So Scheduler Pro enforces event positions with a constraint. And then start/end dates are calculated. To prevent this you can: turn the ev...

Hello,

Project has a config limiting calendars iteration timspan: https://bryntum.com/products/schedulerpro/docs/api/SchedulerPro/model/ProjectModel#config-maxCalendarRange
You need to adjust it accordingly in case you deal with large timespans.

Best regards,
Arcady

Hello, A store by default doesn't re-apply filters on records adding. Try adding this code after the view store before setting the filter: resourceUtilization.store.reapplyFilterOnAdd = true; I've made a ticket to enable it by default on the class: https://github.com/bryntum/support/issues/8963 Than...
Hello, The project startDate is a required value based on which all tasks are scheduled. The tasks are scheduled ASAP given the earliest possible date is the project start. So moving the date causes moving of the project tasks (this is what you reported in this post). It's meant to be provided ..if ...

Ok I'm glad it works. Here is a ticket I've made for the issue: https://github.com/bryntum/support/issues/8956
Thank you for the feedback!

Actually I think I know what could happen. Please check if this workaround helps you and let me know: new TimelineHistogram({ listeners : { beforeRenderHistogramRow({ source, record, histogramConfig }) { const { data } = histogramConfig; // if previous calculated bar widths is not up-to-date if (sou...
Hello, In the attached images in both cases I am providing TimeLineHistogram the exact same 4 series data points, but as you can see, they are displayed very differently. We need a test case to reproduce this or steps how this can be reproduced on some of our demos. Otherwise it's hard to guess what...