Closed
Bug 406588
Opened 17 years ago
Closed 5 years ago
Document valid actions for nsITreeView.performAction*
Categories
(Core :: XUL, defect)
Core
XUL
Tracking
()
RESOLVED
INVALID
People
(Reporter: WeirdAl, Unassigned)
Details
From a thread I started on m.d.t.xul:
> I have finally been convinced - after seeing nsTreeContentView.cpp -
> that I should at least try to build a tree view component instead of
> blindly adding <xul:treeitem/> elements everywhere. Yet I am confused
> by the existence of three methods on the nsITreeView interface:
> performAction, performActionOnRow, performActionOnCell. In particular,
> these methods seem unused in the code base - I see no one calling it,
> and most implementations are null ops.
Either we need to document what the valid actions are, or these methods need to die.
Updated•17 years ago
|
Version: unspecified → Trunk
Reporter | ||
Comment 1•17 years ago
|
||
<Enn> there is a place where those functions are used I think <Enn> I wouldn't worry about it until bug 350264 is worked on <Enn> i think its was intended to be like commands but for specific items, cells, etc <WeirdAl>I have no problem leaving the methods there, if we document what the valid actions are, or what the intent is. <Enn> weirdal: you make them up <WeirdAl> Enn: it'd be really, really, really nice if the IDL would have just said that... <WeirdAl> "Implementers of this interface define the set of valid actions for consumers."
Summary: Document valid actions for nsITreeView.performAction*, or remove the methods → Document valid actions for nsITreeView.performAction*
Component: XP Toolkit/Widgets: Trees → XUL
QA Contact: xptoolkit.trees → xptoolkit.widgets
Comment 2•7 years ago
|
||
I am trying to resurrect some code that adds search / filtering in the message filters list on SeaMonkey through my (XUL based) addon quickFilters. I suspect the "delete" action has never been properly tested, I am going through a loop removing non-matching filters, like this: for (let i = rows - 1; i>=0; i--){ // http://mxr.mozilla.org/comm-central/source/suite/mailnews/search/FilterListDialog.js // SeaMonkey item = getFilter(i); // SM / Postbox: defined in FilterListDialog.js title = item.filterName; if (title.toLocaleLowerCase().indexOf(keyWord) === -1){ filterList.view.performActionOnRow("delete", i); // the view is same as gFilterTreeView filterList.boxObject.invalidateRow(i); filterList.boxObject.rowCountChanged(i+1, -1); // was i + 1 -- same as gFilterTreeView.tree hiddenCount++; // problem: gFilterTreeView.filterList is not updated; see setServer(uri) in FilterListDialog.js // maybe we can replace set filterList(val) { ... } // this.mFilterList = val => replace with the "filtered" values } } The problem is the rowCountChanged seems to only always remove the _last_ item in the list - (ignored the efirst parameter?) after calling invalidateRow(i). I made sure to iterate the array backwards from the end. I don't want to remove anything from the underlying data structure (the editable filter list) just hide from the view what doesn't fit with the filter criteria (in above example the name but in Thunderbird I have more powerful filter methods) Any ideas on how to fix it? Can I somehow access the XUL contents and make them invisbile or does the CPP implementation make this impossible for any script.
Reporter | ||
Comment 3•5 years ago
|
||
I just killed the performAction* API's a couple of weeks ago.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•