Does not limit the names of files to maxim. 25 characters.
Seems like a bug to me.
Besides: It seems also logical and desirable that this works for other folder lists, such as:
Go CURRENT FOLDERCONTENT="norecurse,nofiles,maxdirs=30,maxwidth=25"
In this case too, file names are not limited - but I can't call it a bug because the manual on GO FOLDERCONTENT does not contain this parameter. If it was supported there, I would certainly use it there too, because files can have really long names.
I am using the most recent version of DO:
13.15.3 (Beta) x64, build 9281.
Great.
Is it also planned to work for FOLDERCONTENT? Because, just like TABLIST, its a list of files, so it would only be logical for it to be applicable there as well. And I have a specific reason for needing it.
@Leo I think I saw another buggy FOLDERCONTENT parameter. In the following command:
Go CURRENT FOLDERCONTENT="showempty,noparselinks,norecurse,nofiles,maxdirs=30,maxwidth=25,includestart"
the 'includestart' part does not work (and it doesn't work if I put it at the beginning either). I should perhaps say it more precisely: including this parameter results in all the other parameters not working anymore: only the name of the 'startfolder' is suddenly shown (the current folder) and the folder content became absent.
I solved it by putting an extra button in front of the folder list, with only the command:
Go CURRENT FOLDERCONTENT="includestart"
By doing so, I got the desired effect, so I'm fine. But according to the description of this functionality, I seems that this should not require two separate buttons. Correct?
From the manual: The generated content list begins at the specified folder rather than starting with its contents.
So it sounds rather logic that you now only have one folder generated, which is the one you specified.
Without the norecurse, you'd be able to navigate to the subfolders from there (following the arrow at the end of the startdir), but since you did add no recurse, you're now just left with the starting folder.
Combining these two options is not giving you something much usable.
@PassThePeas Hmm - to be honest, I'm not convinced by your explanation. It seems like I should still see the immediate subfolders (without recurse indeed). With your explanation it sounds like there's some kind of nomansland between parent folder and subfolders - and FOLDERCONTENT="includestart" was indeed meant to always just show the name of the current folder - which makes me wonder why the option wasn't simply called "showcurrent" rather than suggesting it "includes" something. If you know what I mean.
I see what you mean. Maybe the option name is not the best, and something like startfromcurrent would be more explicit.
Yet, the described behaviour seems coherent to me:
Options
Behaviour
<none>
Displays all subfolders, they are browsable/expandable
includestart
Starts one folder up in the hierarchy (e.g. from the specified path). All displayed folders are expandable (starting from the first one)
norecurse
Displays all subfolders, they are NOT browsable/expandable
includestart,norecurse
Starts one folder up in the hierarchy (e.g. from the specified path). All displayed folders (e.g. only the first one) are NOT expandable
As I said, that combination (includestart,norecurse) is quite useless.
But the most important part, is what are you trying to achieve?
You would like to have the first level as the current folder, expandable, then, when expanded, the list of subfolders, but this time not expandable?
If so, I don't think this is a behaviour you'll be able to get from the raw GO FOLDERCONTENT command, but I might be wrong.
OTOH this should be achievable through scripting, especially now that we have a way to create dynamic buttons.
@PassThePeas Thank you for your explanation. I'll accept it.
The reason why I was asking? That has something todo with my vertical toolbar which I use to replace the "directory tree" of Directory Opus. If you look at my "tutorial" linked below, espcially in the second screenshot, the one at the very end, you will see why I wanted that extra functionality bit. And by using an additional button, it just works perfectly fine now.
I think you're correct that at this point, you can either:
Use two buttons to see both the parent and then a list of its subfolders - but this requires extra clicks, as in C; Folder Options (1).dcf (1.9 KB)
or
Use one button to go directly to the subfolders in the file display bypassing a list of subfolders requiring fewer clicks - but losing the FOLDERCONTENT feature of navigating in folders, as in C; Folder Options (2).dcf (1.7 KB)
@jinsight
Yes that makes sense. I did it with two buttons. But, as you say "this requires extra clicks", I assume you talk about a different usage. In my case, as explained in my tutorial "An Alternative Directory Tree" (see the link somewhere above) I only click on one of the subfolders in order to browse deeper down the tree. The button to display the current folder just serves for... displaying it. It feels a bit silly to use a button just to display something, but I'm just just using what I have, for lack of something else.
@Leo @Jon (who wrote the update of DO version 13.16.2, Beta)
I'm not sure if I need to create a new topic for clarity. The 'maxwidth' parameter now works great also for FOLDERCONTENT.
But it does not solve my problem, because in my vertical toolbar I do not only use
Go FOLDERCONTENT
Go TABLIST
But also
Go BACKLIST
which is in the same league, in need of the maxwidth parameter, because once I've visited a folder with a long name, or containing files with a long name, it appears in the backlist in its full length, stretching my toolbar all the way. (I'm talking about my post "An Alternative Directory Tree", see the link somewhere above).
Can you confirm that this note has been captured for review? Otherwise I'll make it a new post if that's better.
Yeah, funny. But I was just asking if it can be put on your list. I know it's a very minor issue, but hey, we're all happy if DO is a great and consistent working product, isn't it? I'm just putting in my little contribution to that here. I know it's not all about me.
