Hello,
After clicking a lot, I’m embarrassed by what seems to be a kind of issue, but is there a solution ?
Part 1 : the situation
It’s about the pointer of the mouse and the detection of the current date which is accessible via getActionData()[‘date’].
By example, on the time slot 04:00-05:00 with a time_step of 5 minutes,
- clicking between 04:00 and 04:05 (even including 04:00) create an event starting at 04:05 ;
- clicking between 03:55 and 04:00 create an event starting at 04:00.
Working with a scheduler and all its rule imposes to be very precise and here I think there is a little issue. Reading the next will introduce a perturbing “use case”.
Part 2 : by the example
To explicit the case, I have created on an empty scheduler two marked timespans, the first with dhx_time_block type (and class “im_blocked”) and the other without (and class “im_not_blocked”).
I have added a “onBeforeDrag” event to show which HTML element was the target of the trigger.
The next after the code block.
Here an example for processing a test if needed, to use on the week view with the current date :
[code]// config
scheduler.config.multi_day = true;
scheduler.config.xml_date="%Y-%m-%d %H:%i";
scheduler.config.details_on_create = true;
// add onBeforeDrag
scheduler.attachEvent(‘onBeforeDrag’, function(id, mode, e){
console.info(‘Event::onBeforeDrag() target’, e.target||e.srcElement);
return true;
});
// init scheduler
scheduler.init(‘scheduler_here’,new Date(),“week”);
// add marked timespan ‘Blocked’
var startDate = new Date();
startDate.setHours(3); startDate.setMinutes(0); startDate.setSeconds(0);
var endDate = scheduler.date.add(startDate, 60, “minute”);
console.log(‘startDate / endDate’, startDate, endDate);
var blocSpan = scheduler.markTimespan({
start_date: startDate,
end_date: endDate,
css: ‘im_blocked’,
type: ‘dhx_time_block’,
html: ‘Blocked’
});
blocSpan[0].style.backgroundColor = ‘red’;
// add marked timespan ‘Not blocked’
var startDate = new Date();
startDate.setDate(startDate.getDate() + 1);startDate.setHours(3); startDate.setMinutes(0); startDate.setSeconds(0);
var endDate = scheduler.date.add(startDate, 60, “minute”);
console.log(‘startDate / endDate’, startDate, endDate);
var blocSpan2 = scheduler.markTimespan({
start_date: startDate,
end_date: endDate,
css: ‘im_not_blocked’,
html: ‘Not blocked’
});
blocSpan2[0].style.backgroundColor = ‘green’;
[/code]
Part 3 : the tests
First timespan (blocked)
Case 1 : If we click on 03:55 (on the blocked timespan), nothing happens : normal !
Case 2 : If we click on 04:00 (after the timespan), onBeforeDrag is triggered… with <div class="dhx_scale_holder_now ", allowing to create an event starting at 04:05 if double-click : normal !
Second timespan (not blocked)
Case 3 : If we click on 03:55 (on the not blocked timespan), onBeforeDrag is triggered… with <div class=“dhx_marked_timespan im_not_blocked”, allowing to create an event starting at 04:00 : not really normal !
Case 4 : If we click on 04:00 (after the timespan), onBeforeDrag is triggered… with <div class="dhx_scale_holder_now ", allowing to create an event starting at 04:05 if double-click : normal !
The case 3 shows that clicking on a timespan (whose height go from 03:00 to 04:00) creates an event starting at 04:00.
Part 4 : is there an issue ?
The first issue, for me, is that on a blocked timespan it is not easy to create an event starting at the time where the timespan finishes.
The second issue is that this behavior break some customizaton possibilities.
An example : I add a marked timespam (not blocked) in the scheduler and I want to detect, when I click somewhere (not on an existing event) from where comes the clicks to adapt the creation of my event. If I click on the timespan, I have some properties to my event, if I click not on I want to let the native creation.
I hope my explanations are comprehensible !
What do you think about ? Perhaps am I missing the point ?
Part 5 : related PS
PS: In an other way, while playing with the demo of Highlight and single create ( docs.dhtmlx.com/scheduler/sample … reate.html ), if we remove the fix_date() function to working with native time_step, we can see that the timespan is almost always under the mouse pointer, as if mouth_coords() or _get_date_from_pos() were not dealing with the final position of the pointer.
