1. #1
    Sencha User
    Join Date
    May 2011
    Posts
    70
    Answers
    4
    Vote Rating
    0
    gnube is on a distinguished road

      0  

    Default Unanswered: Forcing redraw of the treePanel

    Unanswered: Forcing redraw of the treePanel


    I have a treePanel I have setup with a bunch of functions including toolbar, context menu, TreeCellEditing and treeviewdragdrop on 4.0.7-gpl

    There are a number of workarounds needed to get various functions to work due to flaws in the control - I started on 4.0.2a so hopefully I have not brought forward anything which is not needed on 4.0.7-gpl.

    Anyways - I seem to have all the store updates and drag and drop working now so I can add nodes and drag them about ok. But...

    On occasion - not infrequently - the treePanel fails to redraw itself correctly. Mainly after performing a TreeCellEditing edit, or dropping a node into a new folder.

    I would like to force the control to redraw itself, when I call treePanel.getView().refresh() there is no visible result - when I close and open my panel it pulls records from the store and renders fine - I know the data is all good - and see no reason why my calls to save my node records would interfere with the tree control.

    I think it is supposed to be handling its tree and redraws via the DD, TreeCellEditing and appendChild facilities all by itself. I suspect rendering bugs in the control but would like to workaround them with a refresh.

    Any ideas how I can force it to draw?
    Thx

  2. #2
    Sencha - Senior Forum Manager mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    37,015
    Answers
    3491
    Vote Rating
    847
    mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute

      0  

    Default


    When the redraw fails, have you checked the DOM to see what is rendered and the size of things?
    Mitchell Simoens @SenchaMitch
    Sencha Inc, Senior Forum Manager
    ________________
    Check out my GitHub, lots of nice things for Ext JS 4 and Sencha Touch 2
    https://github.com/mitchellsimoens

    Think my support is good? Get more personalized support via a support subscription. https://www.sencha.com/store/

    Need more help with your app? Hire Sencha Services services@sencha.com

    Want to learn Sencha Touch 2? Check out Sencha Touch in Action that is in print!

    When posting code, please use BBCode's CODE tags.

  3. #3
    Sencha User
    Join Date
    May 2011
    Posts
    70
    Answers
    4
    Vote Rating
    0
    gnube is on a distinguished road

      0  

    Default


    Hey Mitchell - I noticed that the rendering which was causing the muddlement in the tree draw seemed to be related to the animation used following receipt of the return value from firing beforeDrop event. I changed my return value from '0' to false which seems to prevent this animation.

    I see the same issue still when I close the TreeCellEditing plugin - which I beleive has problems in my 4.0.7-gpl so have created a subclass based upon fixes from the forums.

    It looks like there is some additional CSS being applied to the tree row which places a folder at the front of the row as it it were a 'root' level row. Hmm I am showing the root node so I should see it hiding this changes the situation at all - should be able to try that a bit later today.


    Code:
    // This is a custom plugin taken from the sencha forums which is designed
    // to fix a bug in the standard cell editing plugin
    Ext.define("DynamicApp.grid.plugin.TreeCellEditing", {
        extend : "Ext.grid.plugin.CellEditing",
        alias : 'widget.CxTreeCellEditing',
    
    
        
        // IE7 breaks otherwise
        startEditByClick: function(view, cell, colIdx, record, row, rowIdx, e) {
            // do not start editing when click occurs on the expander icon
            if (e.getTarget(view.expanderSelector)) {
                return;
            }
            
            this.callParent(arguments);
        },
        
    
    
        startEdit: function(record, columnHeader) {
    // MODIFICATION
            if (!record || !columnHeader) {
                return;
            }
    // EOF MODIFICATION
            
            var me = this,
                ed   = me.getEditor(record, columnHeader),
                value = record.get(columnHeader.dataIndex),
                context = me.getEditingContext(record, columnHeader);
    
    
            record = context.record;
            columnHeader = context.column;
    
    
            // Complete the edit now, before getting the editor's target
            // cell DOM element. Completing the edit causes a view refresh.
            me.completeEdit();
    
    
            // See if the field is editable for the requested record
            if (columnHeader && !columnHeader.getEditor(record)) {
                return false;
            }
            
            if (ed) {
                context.originalValue = context.value = value;
                if (me.beforeEdit(context) === false || me.fireEvent('beforeedit', context) === false || context.cancel) {
                    return false;
                }
    
    
                me.context = context;
                me.setActiveEditor(ed);
                me.setActiveRecord(record);
                me.setActiveColumn(columnHeader);
    
    
    // MODIFICATION
                // Defer, so we have some time between view scroll to sync up the editor
    //                                                    enables the correct tabbing      enables the value adjustment in the 'beforeedit' event 
    //                                                           |                                |    
                me.editTask.delay(15, ed.startEdit, ed, [me.getCell(record, columnHeader), context.value, context]);
    // EOF MODIFICATION
                
            } else {
                // BrowserBug: WebKit & IE refuse to focus the element, rather
                // it will focus it and then immediately focus the body. This
                // temporary hack works for Webkit and IE6. IE7 and 8 are still
                // broken
                me.grid.getView().getEl(columnHeader).focus((Ext.isWebKit || Ext.isIE) ? 10 : false);
            }
        },
    
    
        getEditingContext: function(record, columnHeader) {
            var me = this,
                grid = me.grid,
                store = grid.store,
                rowIdx,
                colIdx,
                view = grid.getView(),
                value;
    
    
            
            if (Ext.isNumber(record)) {
                rowIdx = record;
                record = store.getAt(rowIdx);
            } else {
                if (store.indexOf) {
                    rowIdx = store.indexOf(record);
                } else {
                    rowIdx = view.indexOf(view.getNode(record));
                }
            }
            if (Ext.isNumber(columnHeader)) {
                colIdx = columnHeader;
                columnHeader = grid.headerCt.getHeaderAtIndex(colIdx);
            } else {
                colIdx = columnHeader.getIndex();
            }
    
    
            value = record.get(columnHeader.dataIndex);
            return {
                grid: grid,
                record: record,
                field: columnHeader.dataIndex,
                value: value,
                row: view.getNode(rowIdx),
                column: columnHeader,
                rowIdx: rowIdx,
                colIdx: colIdx
            };
        },
    
    
        startEditByPosition: function(position) {
            var me = this,
                grid = me.grid,
                sm = grid.getSelectionModel(),
                view = me.view,
                node = this.view.getNode(position.row);
    
    
                editColumnHeader = grid.headerCt.getHeaderAtIndex(position.column);
                editRecord = view.getRecord(node);
    
    
            if (sm.selectByPosition) {
                sm.selectByPosition(position);
            }
            me.startEdit(editRecord, editColumnHeader);
        }
    });

  4. #4
    Sencha User
    Join Date
    May 2011
    Posts
    70
    Answers
    4
    Vote Rating
    0
    gnube is on a distinguished road

      0  

    Default


    OK - I tried hiding root from my panel and it made no difference.

    But, I noticed something which may narrow things down a tad. I say "may" because to be honest, this tree control trips me up a lot as I try to learn how to use it.

    Rendering the drop onto the tree seems to go askew when I drag and drop ONTO the folder (isLeaf: false) node. (call this drop style a)

    If I let the folder open, and drop the item inside, when there is a dotted line drawn to indicate the drop position, then the drop is drawn correctly. (call this drop style b)

    It is obviously not possible to drop into an empty folder using drop style b - the line indicates the position in the parent folder....hmmm...

    hmmm... Could be that my derived model writes out how I want the dropped node to position and not how the tree drop wants it to position.

    I think I am correct in assuming that when the drop happens under drop style a, that I should set my record node to the node being dropped onto - this makes sense to me but perhaps it was not considered by the treePanel drop renderer? Or, perhaps I am supposed to change something in the beforeDrop event to signal back to the view??

  5. #5
    Sencha User
    Join Date
    May 2011
    Posts
    70
    Answers
    4
    Vote Rating
    0
    gnube is on a distinguished road

      0  

    Default


    ok - basically I found the best way to deal with the tree for my needs was to return false from the beforeDrop and used the closure function provided ( 4.0.7-gpl)

    this effectively makes the control animate a failed drop, lets me do async processes to update my back end data and once that is complete I call the closure function which animates the drop onto the tree (I can cope with the initial fail animation but not ideal - returning 0 from the event caused duplicates in my tree).

    The key to all this is getting the back end to work exactly as the standard tree control animation is written to behave - get all the combinations of (before/append/after with expanded branch/loaded collapsed branch/never loaded collapsed branch/leaf) and it will basically work.

    The only problem I have is specifically with dropping an append onto a collapsed branch which has never been expanded. Sometimes this will cause the drop closure to put the dropped line at the top of the grid - only fix when that happens seems to be to close the grid and open it again - the data is saving in the correct place, just rendering is nuts. I am using the expand callback to trigger the drop closure so I can't see I can do much more here. Hopefully whatever happens to the control for the next releases helps.

Thread Participants: 1