Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    timeline: issues with dragging events

    Hallo,

    Here is a list with issues I found with dragging events. As a test case you can use the SiemensTimelineTest.java you have sent us.

    1. Events cannot be dragged to seemingly random places.
    Steps to reproduce: take event with ID "TestItem5" and drag it somewhere, then try to drag it back to it's initial location. The cursors becomes a "forbidden" or "no-drop" cursor and the operation is not allowed. Even if the cursor is "no-drop" when the event is dropped, it is moved as close as possible to the location, which is wrong - it should not be moved at all.
    It makes no sense that an event cannot be dragged back to a position it has already been on.
    In general, all events seem to have issues being dropped at certain locations on the timeline with no obvious reason.

    2. Mouse cursor stays in "no-drop" shape.
    Steps to reproduce: start dragging an event and move the mouse cursor outside of the timeline view. Find a place where the cursor changes to a "no-drop" (the mouse must be outside the timline still), then drop the item. The item itself is going to be positioned as close as possible inside the timline (which is correct) but the cursor will permanently take the form of a "forbidden" or "no-drop" cursor.

    SmartClient Version: SNAPSHOT_v10.0d_2014-07-10/Pro Deployment (built 2014-07-10)

    Browser: FF 30.0

    #2
    As we've said before, sample code from more than 6 months ago is of little use. We will need you to provide a test-case that was built against latest code and shows the issues you refer to.

    Comment


      #3
      A quick comment in the meantime -

      1) drops are disallowed if the start or end date of the event being dragged fall on a disabled date - so, this sounds like disableWeekends is true (which it is by default) - try calling setDisableWeekends(false)

      2) we can look at this one
      Last edited by Isomorphic; 23 Jul 2014, 08:18.

      Comment


        #4
        Your point 2) has now been addressed - please retest with a build dated July 25 or later

        Comment


          #5
          A final comment on your point 1)

          It does indeed make sense for an event not to be droppable in some positions, even if it *was* there beforehand. Events being drag-moved/resized with the mouse in a CalendarView cannot be dropped on start or end dates that are disabled. How the events were created with those dates in the first place is unrelated to mouse-based updates.

          When a drop occurs and the noDrop cursor is showing, internal logic allows the drop to occur at the last good drop position. This was by design, and you could have prevented it by installing the Reposition/ResizeStop customizers we added for you.

          That said, on review, we've decided to reverse the default behavior of this "last good position" logic - it will now cancel drops that occur while the noDrop cursor is showing.

          Please retest with a build dated July 25 or later.
          Last edited by Isomorphic; 24 Jul 2014, 03:13.

          Comment


            #6
            Thank you for your replies and suggestions.
            In the end, 1) was an issue on our side - we had a DisableDateCustomizer configured on the timeline and it was preventing the events being dropped at certain places.
            2) Has been fixed with the currently tested build: SmartClient Version: SNAPSHOT_v10.0d_2014-08-05/Pro Deployment (built 2014-08-05)

            Comment

            Working...
            X