Can you please describe in detail what you used the event for?
We are using this to get the Element and ResourceTimeRange record so we can attach a custom element (web component) to the resource time range and set its input.
Support Forum
Search found 20 matches
We're current working on upgrading one of our applications from Bryntum Schedule v3.1.0 to the latest version (v4). One of the issues we've ran into and are unable to fix is the following: In the previous version (3.1.0) it was possible to intercept render events for resource time ranges using the r...
And this was tested on a iPad?
Steps to reproduce should be quite simple. Make sure you have the right device (I don't own any, so I can't check it myself). Hook it up to a debugger and then trigger a "contextmenu" event on the planboard (that is probably a longpress on an iPad, not really sure). I am pretty sure the de...
I don't really see the point in that, but ok.
Just tested it on Chrome (Windows 10). No problems there. So, as I said before this seems to be a device/browser/os specific issue. I'll leave the rest of the testing up to you guys.
That doesn't work because the function is not executed due to the fact that it is wrapped in the following if statements: if (BrowserHelper.isTouchDevice && !BrowserHelper.isAndroid) { if (eventName === 'contextmenu') { // ... EventHelper.createContextMenuWrapper(...) ... } } If I use touch ...
I don't own an iPad, so I cannot reproduce it myself. The error was caught in production on the device of one of the end users. However, since the code is executed for every scheduler instance it doesn't really matter which example you choose. They all experience the same issue.
The impact of this bug is that the scheduler is non-functional for such devices.
We're encountering a runtime error when the Bryntum Scheduler is initialized on certain devices. Our error logging reveals the following runtime error: undefined is not an object (evaluating 'handler.call') The error is thrown in the createContextMenuWrapper function and seems to occur on an iOS 12....