Trying to turn files and directories into a TreeView

Hey everyone,

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.

some example code is as follows

juce::FileChooser chooser {“Choose File”,juce::File::getSpecialLocation(juce::File::userDesktopDirectory), “.wav;.mp3;,aiff;.ogg”,true,false};

    juce::File myFile;
    myFile = chooser.getResult();
    CustomTreeItem item;
    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.

Any one have any help or input???

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;

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?

Thanks you guys, I used your advice and now it works without leak problems.
Please take care and thanks for the help.

No, there is no memory leak here, since TreeViewItem takes ownership of the passed item.

From the documentation of TreeViewItem::addSubItem:

When the items are later removed with removeSubItem() (or when this item is deleted), they will be deleted.

Using a smart pointer would result in a double delete and possibly a crash.

But if setTextOfButton() is not marked as nexcept it might leak, right? It’s probably safer to do it like this:

auto item = std::make_unique<CustomTreeItem>();

Worrying about exceptions in Juce based code is pretty much redundant. Especially in plugin projects there’s no good way to deal with them.

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?

Are you confusing exceptions with asserts/jasserts?

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

OK I know what exceptions are but missed the general exception case with noexcept, thanks.

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: