FileTreeComponent - how to expand tree to selected item

I have a component with FileTreeComponent on it. It shows tree of entire drive. I have a path that I want to select in that tree and make it visible.
Initially thought that it would be enough to call:

setSelectedFile
and then
scrollToKeepItemVisible

but that does not work at all.
I tried to go through all items from the root to the selected node and force expanding by calling setOpen but this does not work too. Only if I expand root node I get proper number of subitems, when I then call setOpen on one of those subitems (knowning for sure that it should have its children) I get number of subitems zero.

Any suggestion how to make it work.
Thanks,
Janusz

the FileTreeComponent needs time to load its sub-trees

In other words, that control is useless. Will have to ditch it and try with list then. Thanks for the info.

J.

Not sure what makes you think any other kind of control would be less “useless”…

Regardless of what kind of tree or list you use, it obviously has to load asynchronously, otherwise it’d block the message thread while it loads the entire tree (potentially taking minutes).

Please don’t get this in any hostile way. I don’t care if thread must block or not, what I care about is that control does what it was designed for. This is a file system browsing component, it should allow me to browse files, select them and also highlight them for user if needed.
If that means that thread must block for a moment to get portion of a tree so be it. If I’m to take file browsing component just to write code to make it work, I could just take regular tree control and write it myself (again, no offence).

Cheers,
J.

I’m not offended, I just don’t think you understand what you’re asking (or I’ve misunderstood what you mean).

Yep, that’s exactly what it does. But you seem to be asking for something that does this synchronously. All I’m saying is that you can’t write a naive function that blocks while all the files get scanned so it can open a sub-folder. You’d need to use a timer or thread with timeouts and fallbacks to do that asynchronously.

Just a side note: File system operations are very unpredictable in terms of, when they finish. Think of NFS or SMB folders, could take a while. Or even an encrypted disk, which won’t come available unless the password was entered. Not a good idea, to block the message thread by default until this happens…

An idea would be, to check with a timer, until this file is read into the folder structure and call this scrollToKeepItemVisible (haven’t checked the actual calls necessary).

I thought first, the FileBrowserListener could be helpful here, but it isn’t. Maybe that could be added?

(just read now, that’s what jules suggested as well…)

It’s like me giving you my program for say uploading files and saying, “well it works as expected you just have to write the upload code yourself”.

J.

I will just state this clearly one more time. For me ‘a control’ is a black box. I don’t care how it does things under the hood as long as I get expected behavior. If interface provides functions to select files in the tree, expanding nodes to see more files, making item visible, than I take for granted that those functions do exactly that. If it is expected that I write my own code to make the control do that then that should be at least clearly stated in docs.

If the file system is a problem and may introduce delays, the control should take that into account (provide dialog to break, whatever) but not do nothing and say that everything is ok.

J.

If your attitude is that the controls should all behave the way you describe (compelletly self sufficient, no additional code needed), then you won’t like JUCE.

In order for JUCE to be so generic that it can be used for pretty much anything you can think of, it requires the developer to do some of the specific work himself.

I’ve only played around with it for 2-3 months, and I have found very few cases in which I could use the component like it is. You pretty much always have to roll your own by inheritance and overwriting the appropriate functions and callbacks.

If you’re not willing to do that, then JUCE is not for you. With great power comes great responsibility.

I use JUCE for few months now and so far it was a very positive experience. The file tree component is the first thing that disappoints me a little. This is not ‘my attitude’, this is common sense. Read any article about software components to see my point (here’s one: https://en.wikipedia.org/wiki/Component-based_software_engineering).

Regards,
J.

Frustrating to hear that you’re having a negative experience with this class when it’s designed the way it is for good reasons! I tried to explain this above in the hope that you’d get the point and understand why what you’re asking may seem reasonable at first glance, but is actually not practical when you think about it more carefully.

Do you really think it should block the message thread (and what… maybe run a modal loop…?) for an indefinite period while it waits for the file system to be scanned?? That’s just not how anyone designs APIs nowadays. Modal loops and blocking are the worst sins a library designer can make; all modern design leans towards being asynchronous for very very good reasons.

…and it’s not even hard for you to do what you’re asking: just kick off a timer that repeatedly tries to open/select the file and gives up after a few seconds. That’s like 10 lines of easy code.

Again, you want me to correct for something that component should do out of the box. Somehow component can show proper tree when I expand nodes using mouse (I assume it must also be prepared for file system delays), why it cannot do the same when I use code instead of mouse.
I think, you are focusing to much on this ‘waiting thing’. Let’s be honest, 99.9% of time file system just works and allows user to pick files and continue. If there are long delays in file system, it means that IT must step in and upgrade hardware or be fired for not doing so.

J.

As I wrote previous post I realized why I’m so frustrated at the component. I would understand your explanation that I must write that 10 lines if nothing happend after clicking tree node. Then at least I would get the idea of you wanting me to write part of the component.
But I have put component, it worked nicly, I was able to pick file and do rest of work. Then next task came: show the file picked before and now component does not do what I expected.

J.

It would be a good new feature for FileTreeComponent to support all this async restore/reveal logic though. A good solution might add in a progress bar and a cancel button when working on longer-latency file systems.