Item Count in Tab Name

Perfect... THANK YOU!

Playing with the code, I wanted to eliminate the tab name change if the tab had no items, so changed the relevant code from this:

cmd.SetSourceTab(tabItem);
if (tabItem.all.count != 0) {
cmd.RunCommand('Go TABNAME="' + newTabName + '"');}

to this:

cmd.SetSourceTab(tabItem);
if (tabItem.all.count != 0) {
cmd.RunCommand('Go TABNAME="' + newTabName + '"');}

The script works very well with two exceptions:

  • when adding a new folder or file (requires tab refresh)
  • when deleting or moving a folder or file (the losing tab, especially Desktop, requires close then reopen)

As an aside, there is an "Invalid procedure call or argument (0x800a0005)" error at line 45 position 9:

var tabPath = fsu.Resolve(tabItem.path);

Otherwise, this works great. Thanks again!

I updated the script. Works now better with File Collections as well.

That's odd. I included a debug line in the script. Let me know which tabs cause trouble.

Thanks again for this. The error occurs when opening a lister that includes a Desktop tab. In addition, the Desktop tab causes two issues:

  1. Counts for the desktop tab only update when adding an item; removing items (move, delete) does not change the count.
  2. Starting in the Desktop tab, selecting another folder within the tab (e.g. File Collections), then moving back to the Desktop tab does NOT change the name of the tab back to Desktop. The name remains that of the previous folder (e.g. File Collections).

EDIT: Error occurs when opening a lister, regardless of which tabs are included. Could this be related to another script running on Lister open?

The script not detecting an update means we need to find the event that get triggered by the action (if there is such an event) and add it to the list of events in the script. I'll have a look.

Could be. I never had such an error, so there is hope :slight_smile:

To detect folder changes in a script, you'd need to use a Dialog and the WatchTab method. (The dialog's opacity can be set to zero so it's never visible.)

1 Like

Follow Up: I disabled all other scripts and restarted DOpus via dopusrt.exe /restart. Even with only the EventRenameTabItemCount script enabled, the error persists regardless of lister configuration or tabs displayed.

The OnOpenLister and OnOpenTab events sometimes send empty path objects, that cause these errors. I have updated the script to skip these tabs. FTP tabs will now look nicer, too.

I have added debug info to the script output. They can easily be suppressed by prefixing all DOpus.Output statements with //.

3 Likes

Works like a champ, thanks!

2lxp

Can you tell me a way to modify the code to display only the number of files or only the number of subfolders? TIA

Replace

var c = tabItem.all.count;

with

var c = tabItem.files.count;

or

var c = tabItem.dirs.count;
1 Like

2lxp
Much appreciated!

Revisiting this based on a recent quirk I noticed: hidden items (I'm sure the same issue exists for system items)

When in a tab with hidden items, the tab provides the correct number of items displayed. Clicking the "Hidden Files" link in the status bar displays the hidden files, but does not update the item count in the tab name unless one explicitly refreshes the tab. The same issue applies when hidden files are displayed and one clicks "Everything" in the status bar.

What object/event/method might we use to refresh the tab item count when displaying or hiding hidden files?

Hi @lxp was that detail fixed? Why do I have your second version of the script and I have to update the tab when I create new files/folders, or is it a wrong behavior of my PC? Thank you

I am afraid there is no event that gets triggered in that case.

No. Why not?

I just wanted to know why if you messed up that detail in the script, it's my PC that has a problem because when copying, pasting, creating new documents, etc., it doesn't update the number of these

The link I have posted leads to the explanation. Would you mind reading it?

Surely yes, I'm going to read it right now, thank you very much!

Thanks @lxp for confirming my suspicion.