Hi,
I've run into a problem during drag'n'drop in the following scenario:
-a canvas that acts as potential drop targets in the background.
-a listgrid that is z-index-wise on top of this canvas.
-another canvas that was equipped with a getDragData()-method to allow a drop on the listgrid that gets dragged around. The canvas is intended to be droppable on the background canvas and the listgrid.
- INTERSECT_WITH_RECT is used as drag intersect style.
Now, when the dragged canvas enters the area shared by listgrid and background canvas, I got error messages in my log, telling me that in
EventHandler.js, line 3747 a "cmCommonScopeAncestor.parentElement" was not defined. That's in the getDropTarget-function.
As far as I can recognize, the following happens:
getDropTarget tries to get the nearest fit for the drop target from several candiates;
it checks at one point if the intermediate "currentMatch" is a child of the next examined candidate (line 3722)
- but -
the other way round is never checked (i.e. whether the next candidate is a child of the "currentMatch").
The remaining logic assumes that this is not the case and then runs into the experienced problem when hunting a non existing common parent for those two candidates.
As a remedy I added an additional check at line 3727:
, and the dragging then worked flawlessly, since in the case "nearestMatch is child of currentMatch" nothing else needs to be done, since the child already is the nearestMatch and no common ancestor needs to be found.
Is the situation that occured (the next candidate is a child of the "currentMatch")) supposed to happen, but not handled or did I manage to seriously screw up my parent-child relations on my widgets? Lazy as I am, I didn't even start to analyze the buildup of EH._dropRegistry, which delivers the candidates.
Greetings,
Klaus
Be sure your post includes:
1. the SmartGWT or SmartClient version and browser version(s) involved;
SmartGWT 2.5, nightly build 2012-01-23 (I only checked the correction on an older nightly build 2011-09-25, which must be around rev 1858; but I assume it still works on a recent build, the logic in getDropTarget is still the same).
3. for a client-side problem, the contents of the Developer Console (see FAQ for usage);
see attachment, dragndrop and Eventhandler are set to debug.
4. if there is a JavaScript error, the stack trace logged in the Developer Console (from Internet Explorer if possible); and
see attachment.
5. sample code.
Well, the snippet of the additional check is a sample code for a solution, I hope that counts...
I've run into a problem during drag'n'drop in the following scenario:
-a canvas that acts as potential drop targets in the background.
-a listgrid that is z-index-wise on top of this canvas.
-another canvas that was equipped with a getDragData()-method to allow a drop on the listgrid that gets dragged around. The canvas is intended to be droppable on the background canvas and the listgrid.
- INTERSECT_WITH_RECT is used as drag intersect style.
Now, when the dragged canvas enters the area shared by listgrid and background canvas, I got error messages in my log, telling me that in
EventHandler.js, line 3747 a "cmCommonScopeAncestor.parentElement" was not defined. That's in the getDropTarget-function.
As far as I can recognize, the following happens:
getDropTarget tries to get the nearest fit for the drop target from several candiates;
it checks at one point if the intermediate "currentMatch" is a child of the next examined candidate (line 3722)
- but -
the other way round is never checked (i.e. whether the next candidate is a child of the "currentMatch").
The remaining logic assumes that this is not the case and then runs into the experienced problem when hunting a non existing common parent for those two candidates.
As a remedy I added an additional check at line 3727:
Code:
} else if (
!currentMatch.contains(nearestMatch, true) &&
target.dragIntersectStyle == EH.INTERSECT_WITH_RECT) {
Is the situation that occured (the next candidate is a child of the "currentMatch")) supposed to happen, but not handled or did I manage to seriously screw up my parent-child relations on my widgets? Lazy as I am, I didn't even start to analyze the buildup of EH._dropRegistry, which delivers the candidates.
Greetings,
Klaus
Be sure your post includes:
1. the SmartGWT or SmartClient version and browser version(s) involved;
SmartGWT 2.5, nightly build 2012-01-23 (I only checked the correction on an older nightly build 2011-09-25, which must be around rev 1858; but I assume it still works on a recent build, the logic in getDropTarget is still the same).
3. for a client-side problem, the contents of the Developer Console (see FAQ for usage);
see attachment, dragndrop and Eventhandler are set to debug.
4. if there is a JavaScript error, the stack trace logged in the Developer Console (from Internet Explorer if possible); and
see attachment.
5. sample code.
Well, the snippet of the additional check is a sample code for a solution, I hope that counts...