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

  • TreeGrid folderDrop optional callback parameter

    Version: v10.1p_2016-02-24/PowerEdition Deployment (built 2016-02-24)

    I am unable to define folderDrop to recognize the optional callback parameter. As per the guidance in the documentation I have tried various way to define the argument using these constructs:
    a function
    A string containing an expression to evaluate
    An object with the following properties:
    - target: fire in the scope of this target - when the action fires, the target will be available as this.
    - methodName: if specified we'll check for a method on the target object with this name.

    The event signature doesn't seem to allow anything with ", ' , {, or . in the parameter definition. It will accept a simple string with no special character specifying an object . I have tried adding a function as a property of the application defined class via addProperties. In these attempts the callback parameter undefined or not available at runtime I have considered the possibility of invoking the superClass version at the end on my override but an not clear on how to add a callback parameter to the native arguments structure. Below are the scenarios I've tried (I have a attached a subset of the class definition for context. The ones prefixed with an * represent syntax errors:

    * // folderDrop: function(nodes, folder, index, sourceWidget, function(){isc.say"Test"}) {
    * // folderDrop: function(nodes, folder, index, sourceWidget, "function(){isc.say"Test"}") {
    * // folderDrop: function(nodes, folder, index, sourceWidget, "true") {
    * // folderDrop: function(nodes, folder, index, sourceWidget, {target:this, methodName:event}) {
    * // folderDrop: function(nodes, folder, index, sourceWidget, var n = {target:this, methodName:event} ) {
    * // folderDrop: function(nodes, folder, index, sourceWidget, var n = {target:this, methodName:event} ) {
    * // folderDrop: function(nodes, folder, index, sourceWidget, new Object() ) {
    * // folderDrop: function(nodes, folder, index, sourceWidget, this.myCallback ) {
    * // folderDrop: function(nodes, folder, index, sourceWidget, myCallback ) {
    // folderDrop: function(nodes, folder, index, sourceWidget, yetAnotherCallback ) {
    // folderDrop: function(nodes, folder, index, sourceWidget, biomarkerEditor_yetAnotherCallback ) {

    Thanks for any guidance,
    Attached Files

  • #2
    Since you are implementing the method folderDrop, you declare the callback like any other parameter, eg just "callback".

    This callback would be something for your code to execute, by calling it. However, current framework code doesn't pass a callback to folderDrop, so we are looking at removing the parameter.

    If what you want is for the default action to take place, and to get a notification of completion, you can call transferNodes() with the exact arguments passed to folderDrop (this is the default implementation), and transferNodes() takes a callback parameter.


    • #3
      The behavior you describe is exactly what I am looking for, i.e have a callback fire when the nodes have been moved. However I am not clear on how to specify the callback that transferNodes will use when the native TreeGrid framework fires the transferNode event.

      Here is the current signature of the event handler in the TreeGrid:
      transferNodes: function(nodes, folder, index, sourceWidget, callback) {

      The callback parameter is always undefined when the TreeGrid fires the transferNodes event as a result of dragging nodes.

      If I call the event directly from another component such as:
      biomarkerEditor_markers_treeGrid.transferNodes(selectedNodes,folder, null, biomarkerEditor_markers_treeGrid, biomarkerEditor.myCallback );

      ...the transferNode event does get passed the callback function but the callback never fires when debugging in Chrome Version 60.0.3112.113 (Official Build) (64-bit).


      • #4
        Note that transferNodes is not an even. It's a method you can call and pass a callback. The line of code you showed below does show using it correctly (to the extent we can tell from just one line..).

        We have a lot of automated tests that exercise the transferNodes() method and its callback. If you believe there's a case where it doesn't fire and should, we'll need to see a minimal, ready-to-run test case that shows the misbehavior.


        • #5
          Thank you for your feedback. The transferNodes callback is indeed working. I am still having a challenge with my use case implementation however. What I am needing is a way to scroll to the selected record in the tree after the drop has completed. In a sceanrio where the drop target folder has dozens of members the scrollToRow scrolls the selected record off the screen. I unsuccessfully tried adding a callback to transferNodes and then saw the documentation for dragComplete which asserts dragComplete is a definitive way to know when all aspects of the drop operation are complete (This solution is using the default folderDRop/transferNodes scenario.

          dragComplete: function(){
          var selectedRecords = biomarkerEditor.markerTree.getSelectedRecords();
          var row = biomarkerEditor.markerTree.getRecordIndex(selectedRecords[0]);
          } ,

 there something obvious in this impleletation that needs to be modified. I was thinking it has something to do with the view port at the time of the scrollToRow call: Here are the properties set on the TreeGrid:

          dataProperties: {modelType: "parent", parentIdField: "parent"},
          width: "100%",
          height: "100%",
          loadDataOnDemand: false,
          showAllRecords: true,
          showFilterEditor: true,
          canReparentNodes: true,
          // folderIcon: null,
          alternateRecordStyles: true,
          selectionType: "multiple",
          showConnectors: true,
          sortField: "name",
          autoFetchTextMatchStyle: "startsWith",
          canEdit: true,


          • #6
            Have you looked at obvious causes? Are the dropped records selected? Is the recordIndex you get correct?


            • #7
              Yes. But I have been inspecting using the Chrome debugger. I will try adding console logging to see if the values are establishing as expected at runtime without the debuggung latency