So im trying to make a TreeView which uses a concrete class I derived from the TreeViewItem called CustomTreeViewItem. Now the goal is to read every directory and file from my desktop and turn each directory into a node and turn each file into a child of that node. Resembling a typical file tree view of the directory. Im having trouble taking the files getAbsolutePath() string and passing that into my constructor for the CustomTreeViewItem and the adding that CustomTreeViewItem to the tree I had created.
if(chooser.browseForFileToOpen())
{
juce::File myFile;
myFile = chooser.getResult();
CustomTreeItem item;
item.setTextofButton(myFile.getFullPathName());
DBG(item.getText()); //returns the DBG of the text fine....
treeItem.addSubItem(&item); //Its this portion that doesn't work.... It won't add properly as a sub of treeItem which is the root item of the tree I created. I set the treeItem to root using tree.setRoot method.
}
The TreeViewItems have to be heap allocated. Your code allocates a local one on the stack and passes the address of that into the addSubItem call, so it’s not going to work.
You can try something like this instead :
CustomTreeItem* item = new CustomTreeItem;
item->setTextofButton(myFile.getFullPathName());
treeItem.addSubItem(item);
This would work indeed (because now your item is not going to be deleted after the closing bracket),
but also may create a memory leak if you use the old new alloc style and forget to delete that object.
I would consider using modern smart pointers at line 1?
Even in plugin projects, shouldn’t we use the juce plugin host demo (or any similar tool) in debug mode and be able to break on these useful exceptions?
yes, was using assuming they could be juce asserts (generating debug breaks) in that case with the memory leak detection code generated in debug mode but maybe it does not happen ?
Exceptions are a different concept, they are to bail out from code paths that hit an error (throws an exception) to catch it without crashing
Most functions in JUCE are declared noexcept, which means for the compiler “I tell you it will never throw” which saves a few execution cycles at the cost, if it does throw it will crash
Wouldn’t it be it be useful to have them declared NOEXCEPT instead in JUCE and then define a NOEXCEPT macro that can be either set to noexcept or nothing if we want to run a session with the extra exceptions in the debugger (assuming we would get them and hopefully a stack with it in debug mode) ?
EDIT: Created a new thread for this question: