If I create a template in Sitecore that builds out a parent node with 2 child nodes and 4 grandchild nodes, is there any way to have all of those nodes open in the tree when I "insert" that newly created node in the content tree?
example;
-Parent
-Child
Grandchild
Grandchild
-Child
Grandchild
Grandchild
Currently when I insert a new multilevel template the tree focus jumps to that newly created template but it is closed.
example;
+Parent
I assume by multi-level template you're referring to a branch template. If so, I recommend you create an event handler for perhaps item:saved or item:created. Make sure it only runs when the item is of this template. In the handler try something like the following code. It may not be exact but might get you started and you may need to make it more recursive depending on what it does:
string rootId = // get ID of root item in the new tree of items
string message = String.Format("item:refreshchildren(id={0})", rootId);
Sitecore.Context.ClientPage.SendMessage(this, message);
Related
Update:
Turns out I was needlessly complicating things. For the purposes of a context menu, you really only need an arbitrary tree (with a Parent, FirstChild and NextSibling). The best way to visualize a tree for a context menu is just like any other tree, but branching out horizontally instead of vertically. There's never really any need to be able to walk the tree in 4 different directions (Up, Down, Left and Right), because all of the information you need is already there with Parent, FirstChild and NextSibling (all of which is fairly easy to determine if you already have a list of path strings).
This thread can safely be closed.
I'm not using XPath or any web or DOM-related libraries, but I would like to utilize an XPath-style means of populating the contents of a context menu widget:
struct ContextMenuNode
{
ContextMenuNode* Left; // Parent Menu
ContextMenuNode* Right; // Sub Menu
ContextMenuNode* Up; // Previous Sibling
ContextMenuNode* Down; // Next Sibling
FString Path; // An XPath-like string
FString Caption; // Display text of this menu item
}
What I would like to do is something like this:
// Defined in a class declaration:
TArray<ContextMenuNode*> MenuNodes;
// ...
/* This should create 2 unique nodes ("/File" doesn't exist yet within MenuNodes),
establish Left & Right relationships between them, and
return the newly created "/File/Open" node,
adding both nodes into MenuNodes
*/
auto openFileNode = AddNode("/File/Open");
/* Much like the previous line, this should
create 1 unique node (since "/File" should already exist from the previous call),
Left should be "/File", Up should be "/File/Open".
But also, we need to update THOSE nodes in relation to this node now...
Both "/File/Open" and "/File/Save" are Up/Down siblings with the same Left ("/File")
*/
auto saveFileNode = AddNode("/File/Save");
How can this be achieved, or is there simply a better way of going about this?
Useful links for those who are unfamiliar with UE4:
FString: https://api.unrealengine.com/INT/API/Runtime/Core/Containers/FString/index.html
TArray: http://api.unrealengine.com/INT/API/Runtime/Core/Containers/TArray/index.html
My application is displaying a Hugh amount of files system entries held in memory using a ctreectrl , adding all the items takes ~20seconds even when using SetRedraw(False) , so how to make a completely virtual(breadth,depth) ctreectrl & how to populate it ?
Edit#1
I want to display the displayed portion items expanded from the beginning , but I don't want to store them in the tree, for example
Root-->
Child1-->
SubChile1
Child2
Child3
you must not add all items at once. you must add only top level items with cChildren = I_CHILDRENCALLBACK
and handle WM_NOTIFY
with code == TVN_GETDISPINFO if mask & TVIF_CHILDREN set
cChildren (TRUE or FALSE)
with code == TVN_ITEMEXPANDING, action == TVE_EXPAND - expand
node - add only direct child items (one level) again with
cChildren = I_CHILDRENCALLBACK
and possible
with code == TVN_ITEMEXPANDED, action == TVE_COLLAPSE - collapse
node - remove all childs
sense of cChildren = I_CHILDRENCALLBACK - if you add folder to list, you not need at once initialize it (open handle, enum childs) - only when you first time got I_CHILDRENCALLBACK (this when your item become visible, but if containing folder large enough(like system32) - it have too many items, but visible only several top at begin, new begin visible when user scroll down)- open folder, determinate are it have subitems (and based on this set cChildren) but not full enumerate it (do this only on <TVN_ITEMEXPANDING, TVE_EXPAND>
I have no advice to make it virtual.
I use for large tree structures the possibility of collecting a child branch only when it is need. I trap TVN_ITEMEXPANDING
So how to do it: First read the first level (root), than keep all root node collapsed and read all child nodes of the root (just 1 level deep) and populate them.
When a node expands, you already have the nodes, now read the next level below the childs of the expanding node.
So you see only the expanded nodes plus one invisible level.
I do this in this way to show all nodes that are expandable with the + sign. All nodes without children nodes are shown without it as leafs.
The second way is not to fill the string data and let the tree load it via callback. But the impact is small. The real problem with the speed are the number of nodes.
I had a tree control which is being populated some values.And In this few tree nodes consists of
check boxes whereas few doesn't. My problem is Initially when the tree is enumerated the default
selection is on the first root node and this root node consists of three children where each child
consists of check box. Here is my problem exactly is,
Now when I expand the tree and tried to click on the child item which consist of check box(clicking on the check box)
Until the mouse left button down the focus comes to the item we are checking and when the left button click up then
the selection is reverting back to the root item (or to the item which is previously selected).
In order to resolve this this is something I tried,
//TVN_ITEMCHANGED
void CDriverSetupView::OnTvnItemChangedTree(NMHDR *pNMHDR, LRESULT *pResult)
{
NM_TREEVIEW* pNewTreeView = (NM_TREEVIEW*)pNMHDR;
if(NULL != pNewTreeView->itemNew.hItem)
{
m_TreeCtrl.Select(pNewTreeView->itemNew.hItem,TVGN_CARET | TVGN_FIRSTVISIBLE | TVGN_DROPHILITE);
m_TreeCtrl.SelectItem(pNewTreeView->itemNew.hItem);
m_TreeCtrl.SelectDropTarget(pNewTreeView->itemNew.hItem);
}
}
If I am doing like this then I am able to get the selection to whatever the child I am checking everything is cool.
But Initially when launch my application then the tree is is getting expanded and the selection is not on the root item
,it is moving on to the last item .
Please find the below images for better understanding,
When the tree is enumerated without the piece of code in OnTvnItemChangedTree,the tree looks like this,
Now when mouse left button down on the first checkbox the selection seems that it changed to checkbox
item ,
Now when mouse left button up on the checkbox the selection again revert back to the previous node,
Now when I use the piece of code within OnTvnItemChangedTree then I am able to get the selection to the checked node but initially when I launch my application then the tree is getting expanded and the selection is on to the last child item which is as follows,
In the above image I am able to get what I want but the tree is getting expanded and the selection is on to the last item,I know this is because in the pNewTreeView->itemNew.hItem at last after the initialization that item consists handle to the last item ,but how can we make such that initially the tree should not get expanded and selection should properly work when I check on any node then the selection should get changed to the checked item.
Can anyone please let me know how can make the selection to be remained on to the root item and the tree Initial status should
be as not expanded.
I'm probably misunderstanding the question because the solution seems so obvious, but why don't you just collapse the tree and set the focus to the first item when you create it? So after you've added all children?
Finally I solved it .In order to avoid that expand while at the time Initialization and moving the focus from one item to the checked item can be achieved as follows,
For NM_CLICK notification add this piece of code ,which works like charm.
void CMyTreeCtrl::OnNMClickTree(NMHDR *pNMHDR, LRESULT *pResult)
{
if(NULL != pNewTreeView->itemNew.hItem)
{
m_TreeCtrl.Select(pNewTreeView->itemNew.hItem,TVGN_CARET | TVGN_FIRSTVISIBLE | TVGN_DROPHILITE);
m_TreeCtrl.SelectItem(pNewTreeView->itemNew.hItem);
}
}
The only mistake I had done was added this code in OnTvItemChanged Instead I added in OnNMClickTree ,Now finally I achieved what exactly I want.
Look at the following code:
public static void main(String[] args) {
Group group1 = new Group();
Group group2 = new Group();
Label label = new Label("test");
group1.getChildren().add(label);
group2.getChildren().add(label);
System.out.println("Size group1: " +group1.getChildren().size());
System.out.println("Size group2: " +group2.getChildren().size());
}
If the label gets added to group2 it automatically gets removed from group1. Does anyone know why this is intended?
Until now, I do not need the extra functionality e.g. bounds from the group class and use a simple ArrayList to store the references to the label objects.
From the Node documentation:
A node may occur at most once anywhere in the scene graph.
Specifically, a node must appear no more than once in all of the
following: as the root node of a Scene, the children ObservableList of
a Parent, or as the clip of a Node.
...
If a program adds a child node to a Parent (including Group, Region,
etc) and that node is already a child of a different Parent or the
root of a Scene, the node is automatically (and silently) removed from
its former parent.
...
It is possible to rearrange the structure of the scene graph, for
example, to move a subtree from one location in the scene graph to
another. In order to do this, one would normally remove the subtree
from its old location before inserting it at the new location.
However, the subtree will be automatically removed as described above
if the application doesn't explicitly remove it.
When a Node is added to a Scene, the JavaFX system sets and manages attributes specific to that node at that location in the Scene Graph. One example is the location of the node as determined by a parent layout manager and it's constraints. Another is the css style set inherited from parent nodes. Both of these kinds of data may vary depending on the Node's location in the Scene Graph.
If the system allowed you to also place the same Node at another location in the Scene Graph, it would overwrite system calculated attributes determined for the first location. Everything would become very confused - resulting in programs that are difficult to reason about and possessing subtle bugs.
I'm doing something with XML and now I'm confused.
This code works perfectly:
QDomElement new_item = doc.createElement(name);
new_item.setAttribute("type", value.typeName());
new_item.setAttribute("value", value.toString());
doc.elementsByTagName(section).at(0).appendChild(new_item);
But if I would create QDomElement myself (without calling createElement method), then it doesn't get inserted into the document. Something like this doesn't work:
QDomElement new_item;
new_item.setTagName(name);
new_item.setAttribute("type", value.typeName());
new_item.setAttribute("value", value.toString());
doc.elementsByTagName(section).at(0).appendChild(new_item);
Can anyone explain to me why I need to use createElement method ?
Thank you :)
Basically DomElement creation needs information that QDomDocument has. From Qt 4.7 documentation
Since elements, text nodes, comments, processing instructions, etc., cannot exist outside the context of a document, the document class also contains the factory functions needed to create these objects. The node objects created have an ownerDocument() function which associates them with the document within whose context they were created.
http://doc.qt.io/archives/qt-4.7/qdomdocument.html#details (third paragraph)