Trouble with FileTreeComponent/setOpenessS

I’m trying to implement a refresh-Button on my FileTreeComponent(which works great so far), where the openness state gets restored.

First of all, if you creating a structure like this

threadFileBrowser = new TimeSliceThread("threadFileBrowser"); fileList = new DirectoryContentsList (0,*threadFileBrowser); fileTree = new FileTreeComponent (*fileList); threadFileBrowser->startThread (4);

the FileTreeComponent will create a root-Item which has an empty File (FullPath==String::empty, it uses the directory from the DirectoryContentsList ), which will not allow to create a OpenesState, because it creates the UnqiueName from the File which is empty.

If i set the Directory before the FileTreeComponent is created (fileList->setDirectory (rootFile, true, true)), it works, but if i afterwards change the Root-Directoy with fileList->setDirectory, the rootItem in fileTree will be always the same (because it will be only once initiated in the constructor of FileTreeComponent )

So i get a structure like this:

<OPEN id="C:" scrollPos="0">
  <CLOSED id="D:\archiv"/>

But my main problem is, can how can i restore the OpenessState correctly ?
This does not work, does the FileTreeComponent works internally different than other TreeViews?

[code]
if (button==refreshButton)
{
ScopedPointer xml=fileTree->getOpennessState(true);
fileList->refresh();

if (xml!=0)
{
	fileTree->restoreOpennessState(*xml,true);
}

}[/code]

Sorry, I’m struggling to understand the problem…

i want to refresh the FileTree, to update the FileStructure (to see new files etc.)

Because of that i’m doing fileList->refresh(); but than all sub-items are closed.

So i have to restore the openness state

But because DirectoryContentsList loads the files dynamically in a background thread, the restoreOpeness will not work. Because if you open a subitem, it takes a while, to reload its content.

If found a workaround, restoring the update state 10 times in a second, so that the DirectoryContentsList has enough time to reload the subitems. Is there a more elegant solution?

[code]void FileTreeBrowser::buttonClicked( Button* button )
{
if (button==refreshButton)
{
opennesState=fileTree->getOpennessState(true);
fileList->refresh();

	DBG(opennesState->createDocument(String::empty));

	timerCountdown=10;
	startTimer(100);
}

}

void FileTreeBrowser::timerCallback()
{
if (opennesState!=0)
{
DBG(“Restore Openness State”)
fileTree->restoreOpennessState(*opennesState,true);
}

timerCountdown--;

if (timerCountdown<=0)
{
	stopTimer();
}

}[/code]

Ah, I see - that’s a tricky one, I can’t really think of a better way to do it than your hack…

mabye not a main issue, sometimes (not very often) i get this Debug Message when deleting the FileTreeComponent
i guess it has something todo with the icons (last tip)

__crtMessageWindowW(int nRptType=2, const wchar_t * szFile=0x00e1dbc8, const wchar_t * szLine=0x0017a5f4, const wchar_t * szModule=0x00000000, const wchar_t * szUserMessage=0x001785f4) Line 363 + 0x16 bytes C++ _VCrtDbgReportW(int nRptType=2, const wchar_t * szFile=0x00e1dbc8, int nLine=52, const wchar_t * szModule=0x00000000, const wchar_t * szFormat=0x00e1dc40, char * arglist=0x0017f688) Line 670 + 0x28 bytes C _CrtDbgReportWV(int nRptType=2, const wchar_t * szFile=0x00e1dbc8, int nLine=52, const wchar_t * szModule=0x00000000, const wchar_t * szFormat=0x00e1dc40, char * arglist=0x0017f688) Line 241 + 0x1d bytes C++ _CrtDbgReportW(int nRptType=2, const wchar_t * szFile=0x00e1dbc8, int nLine=52, const wchar_t * szModule=0x00000000, const wchar_t * szFormat=0x00e1dc40, ...) Line 258 + 0x1d bytes C++ operator delete(void * pUserData=0x0528c7f8) Line 52 + 0x49 bytes C++ juce::FileListTreeItem::`scalar deleting destructor'() + 0x20 bytes C++ juce::OwnedArray<juce::TreeViewItem,juce::DummyCriticalSection>::clear(const bool deleteObjects=true) Line 85 + 0x3d bytes C++ juce::TreeViewItem::clearSubItems() Line 1197 C++ juce::FileListTreeItem::~FileListTreeItem() Line 78 C++ juce::FileListTreeItem::`scalar deleting destructor'() + 0xf bytes C++ juce::OwnedArray<juce::TreeViewItem,juce::DummyCriticalSection>::clear(const bool deleteObjects=true) Line 85 + 0x3d bytes C++ juce::TreeViewItem::clearSubItems() Line 1197 C++ juce::FileListTreeItem::~FileListTreeItem() Line 78 C++ juce::FileListTreeItem::`scalar deleting destructor'() + 0xf bytes C++ juce::OwnedArray<juce::TreeViewItem,juce::DummyCriticalSection>::clear(const bool deleteObjects=true) Line 85 + 0x3d bytes C++ juce::TreeViewItem::clearSubItems() Line 1197 C++ juce::FileListTreeItem::~FileListTreeItem() Line 78 C++ juce::FileListTreeItem::`scalar deleting destructor'() + 0xf bytes C++ juce::ScopedPointer<juce::TreeViewItem>::~ScopedPointer<juce::TreeViewItem>() Line 83 + 0x2b bytes C++ juce::TreeView::deleteRootItem() Line 519 + 0xf bytes C++ juce::FileTreeComponent::~FileTreeComponent() Line 236 C++ juce::FileTreeComponent::`scalar deleting destructor'() + 0xf bytes C++ juce::ScopedPointer<juce::FileTreeComponent>::~ScopedPointer<juce::FileTreeComponent>() Line 83 + 0x2e bytes C++

Looks like a double deletion, Why do you have a ScopedPointer around your FileTreeComponent? When you add to the tree the TreeView owns it.

[EDIT] - Never mind… I misunderstood the problem(need coffee!)