Hi everybody,
I've discovered a problem that occurs in SectionStacks with members where DragIntersectStyle.RECT is set.
Once the sections where opened and closed, droplines of closed sections get shown during dragging.
You can see the effect in the attached Demo best when you:
- Open all sections of the sectionstack and close all of them again in the order 0,1,2.
- Now reopen the section 1 and start dragging "Canvas 1/0/0" around.
- You get offered droplines of the closed sections, displayed somewhere in the midst of the visible canvases.
After changing sc/client/event/EventHandler.js as follows (snippet starts at line 3696):
, evering works: only the droplines of the opened section's content get used. I just copied the added condition from some lines above where the EH.INTERSECT_WITH_MOUSE-case gets handled.
Is there a chance of integrating the correction into a SmartGWT 2.5 bugfix? (Just to prevent confusion: I've got already another issue running for SmartGWT 2.5 (http://forums.smartclient.com/showthread.php?t=19637) where I also asked if an official bugfix could be made)
Be sure your post includes:
1. the SmartGWT or SmartClient version and browser version(s) involved;
SmartGWT 2.5, nightly build 2011-12-03, Windows Vista, FF 4
3. for a client-side problem, the contents of the Developer Console (see FAQ for usage);
I skipped that, nudge me if you want them for that case.
5. sample code.
See attachments
Greetings,
Klaus
I've discovered a problem that occurs in SectionStacks with members where DragIntersectStyle.RECT is set.
Once the sections where opened and closed, droplines of closed sections get shown during dragging.
You can see the effect in the attached Demo best when you:
- Open all sections of the sectionstack and close all of them again in the order 0,1,2.
- Now reopen the section 1 and start dragging "Canvas 1/0/0" around.
- You get offered droplines of the closed sections, displayed somewhere in the midst of the visible canvases.
After changing sc/client/event/EventHandler.js as follows (snippet starts at line 3696):
Code:
... } else { // check whether dragMoveTarget (tracker, outline, etc) intersects candidate drop target for (;i<length;i++) { var candidate = dropCandidates[i]; if (!canDropOnSelf && candidate == target) continue; if (candidate.intersects(target) && candidate.canAcceptDrop && !candidate.isDisabled() // start added by klausv && ( candidate.visibleAtPoint(event.x, event.y, false, EH._getDragMoveComponents()) ) // end added by klausv ) { matches.add(candidate); } } } //this.logWarn("dropTarget matches" + matches); ...
Is there a chance of integrating the correction into a SmartGWT 2.5 bugfix? (Just to prevent confusion: I've got already another issue running for SmartGWT 2.5 (http://forums.smartclient.com/showthread.php?t=19637) where I also asked if an official bugfix could be made)
Be sure your post includes:
1. the SmartGWT or SmartClient version and browser version(s) involved;
SmartGWT 2.5, nightly build 2011-12-03, Windows Vista, FF 4
3. for a client-side problem, the contents of the Developer Console (see FAQ for usage);
I skipped that, nudge me if you want them for that case.
5. sample code.
See attachments
Greetings,
Klaus