|
|
Rank: Advanced Member
Groups: Member
Joined: 11/15/2008
Posts: 44
|
I am working with TreeView DragDropScope="Global" (using EO 8.0.44.2) with targets that include the treeview itself, another treeview, and a non-EO construct wrapped in a callback_panel. I sure would love more documentation. For example, what is "mode"?
In ~/Demos/TreeView/Programming/Drag Drop to Grid/Demo.aspx line 101 the code is
GridDragTarget.prototype.drop = function(mode, type, data)
In use, the provided parameters are
GridDragTarget.prototype.drop = function(type, mode, data)
Could you provide code EO's code that accomplishes the TreeView DragDropScope="Local" behavior for moving? While I have implemented a drop to my own, non-EO target, I still want the default behavior when the treeview is the drop target. Alternatively, could you advise on how to best identify the treenode under an x,y coordinate. Yes, I can figure out a brute force way to do this, but I am thinking that you have a better.
Thanks so much,
Chris
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Hi,
"Global" and "Local" used to control whether the TreeView to recognize an external drag target. When DragDropScope is set to "Local", drag and drop only works within the TreeView itself. When it is set to "Global", you can drag it to elsewhere. Unfortunately I do not believe you can have both at the same time because there is no public JavaScript API for you add tree node on the client side.
The argument you noticed about drop function is a bug. The correct sequence should be (mode, type, data) in order to be consistent with other methods. We will change that in our next build.
I believe "mode" is a pass through parameter. You can implement a get_DragMode method on your drag source. That method will be called to return a "mode" value, which will be passed to your drop function on your drag target object. Thus a drag source can use "mode" to indicate additional information that maybe useful for the drag target. A typical example is a drag source can return "mode" "1" if ctrl key is down to indicate the drag drop should perform a "copy" instead of a "move", and return "mode" "0" if ctrl key is not down. Usually the drag source will define what value means what, and the drag target then interprets it according to that definition. No EO controls set mode though.
There is no easy way to find out a node under an x, y coordinate. We have such function internally on the TreeView (in order to support the built-in drag drop), but it is not exposed. We will see if we can expose it.
Thanks
|
|
Rank: Advanced Member
Groups: Member
Joined: 11/15/2008
Posts: 44
|
Thank you for the clear, informative response!!
I like the drop fix even though I'll have change my code. Better than the "creat" legacy from K&R C 8)
It would be great if the TreeView equivalent of Grid's findCell could be exposed. I am completing my equivalent but I'll bet EO's is better.
Thanks,
Chris
(If you folks are ever in the market for another enthusiastic software engineer, I'd love working with you folks!)
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
You are very welcome. We will try to expose that function as soon as possible. Our implementation might be better because it has access to all our internal data, so it has some nature advantages. : )
We do not have any opening right now but we will keep your offering in mind!
|
|
Rank: Advanced Member
Groups: Member
Joined: 11/15/2008
Posts: 44
|
Like I need more work ;)
Approach 1: The classic elementFromPoint(x,y)-like approach get's the drag image but not "below" it into the TreeView TreeNodes.
Approach 2: Traverse TreeNodes to determine whether one includes the onDragInTarget x,y. Dropped because I cannot find a way to get the coordinates of a TreeNode.
Approach 3: Beg you folks to tell me which obscured EO method can help. Working on this one 8)
Approach 4: drop the eo_RegisterDragTarget support and write yet-another-drag-drop utility but for EO TreeViews. Seems crazy wasteful.
What are my prospects for the 3rd approach?
Thanks,
Chris
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Hi,
The third approach is the best approach. We won't tell you which obscured EO method though because we DO NOT KNOW whether it will work for you. It was only intended to be used internally so it may have a number of restrictions (such as you have to call another method before calling that method, or the arguments/return values are interpreted differently than you would hoped, etc). In order for you to use it, we have to sort all those out and document them clearly. That means you will have to wait until we make it public. : )
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 11/15/2008
Posts: 44
|
Thanks and cool!! Any thoughts on timing? I can work on other areas in the mean time ... it takes some rigor to shift focus leaving a bit of work uncompleted.
Cheers and Happy New Year!
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
We do not have an ETA yet. We will try to put it out as soon as possible but it will be after the new year for sure.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Hi,
We have posted a new build that added findNode on the client side TreeView object. Please see your private message for the download location.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 11/15/2008
Posts: 44
|
Hooray!! You folks really rock. EO forever!!
|
|