Long delay when right-clicking 39,000 files

In case of many files in many subfolders, display files will still be okay.
However, select all and then rightclick, will cause Opus to crash.



No doubt this is exceptional, but it is too much of a workload to 'split' the task in a few separate sessions.
I used a 3rd party tool to do what I intended to do, so the matter as such is solved.

Above is just for info.

Crashes when right-clicking are unlikely to be because there are a lot of files. It's more likely to be because one/some of the files, combined with one of the shell extensions something has installed on your system, are crashing together.

See Crash, exit or high CPU usage when viewing certain directories for troubleshooting.

That said, looking at your screenshot the program does not look like it has crashed, but like it is busy for a long time. If it comes back eventually, then something is just taking a long time to process 39,000 files, which would not be that unusual as they all have to be passed through all relevant 3rd party shell extensions (and the built-in ones that are part of the OS) to see which menu items they want to add.

Yes, you are right, it took 8 minutes before the context menu showed up. I let it go this time to see what would be happening and how long it would take.
Initially I 'stopped' Opus after 3-4 minutes.


What happens in Explorer if you try the same thing?

Hm... thanks for asking about Explorer: this question revealed that, sadly enough, I forgot to say in my 1st post that I was using a button [Files Only] which button executes:
Set FLATVIEW=Toggle,MixedNoFolders

Sorry for the confusion.

As for the 3rd party tool: I used FlashRenamer to select all the files so to update file-attributes. Sure, FlashRenamer also needed some time to build up the preview entire filelist, but then again it took less than a minute.


I don't understand, are you saying you were right-clicking the FlatView button?

Sounds like he's just relying on FlatView to give him the full list of files in the directory tree which he can't do in Explorer - and so can't say what happens or doesn't happen outside of Opus.

@opw62: I don't think it's fair to compare the speed of something like FlashRenamer loading the file list into it's preview pane vs what happens when you right click them in Opus. Opus is invoking all sorts of non-opus shell extensions and such that FR is not invoking.

If I were you - I would move whatever operation you were trying to access in the right-click menu to some other method... like a toolbar button. You mentioned updating file-attributes, so I assume you have an Opus 'Attributes' command on your context menu that you were trying to get to. There's already an Attributes command on the default Operations toolbar and it's bound to hotkey <Ctrl+B>. If you call it explicitly as opposed to right clicking on the files, you should see a huge improvement in response time since Opus won't have to invoke all the shell extension code ~just to show you the 'Change Attributes & Times' dialog.

By comparison, I have 23,220 files in my day-to-day music collection. If I flatview that folder tree the same as you, then right click on them (a mixture of only .mp3 files and folder.jpg files) then the Opus context menu comes up in about 30 seconds. But I also have NO third-party shell extensions at the root of my context menu. Everything at the root are Opus only commands, with all the third-party and Windows stuff buried under sub-menus. I did this on purpose to speed up my context menu - even though at one time I thought that Opus still invoked some things on right click in such a way that it shouldn't have made a difference - but it did...

At any rate, hitting <Ctrl+B> against that 23k file list allowed the 'Change Attributes & Time' dialog to popup in just about 2 seconds.

As said, I have a button named 'Files Only' executing Set FLATVIEW=Toggle,MixedNoFolders
Once the files are all listed, ctrl-A
Then rightclick to try and bring the context menu.
That takes some 8 minutes.

Right-clicking an enormous number of files, especially ones that aren't all in the same parent directory, is going to take a long time. There's no avoiding that really (except if we imposed an arbitrary limit and only displayed a basic right-click menu with just "Rename" and "Delete" or similar, once a certain number of files are selected).

In that situation, it's best to use toolbar buttons or hotkeys, to avoid having to build the context menu via shell extensions.

What I wrote to Jon, all is well, files are quickly displayed.
Only once do a Ctrl-A and then try to bring up the context menu, that last action (trying to bring up the context menu) takes a while. It'll come up alright, but I was a bit impatient and stopped Opus after 3-4 minutes.
Thing is, one might just simply wait until the context menu comes up and use some other application in the meantime, but once the context menu indeed shows up, switching back to Opus will cause it to disappear again and one needs to start all over.

Anyway, bottom line: just wait ... :wink:

Thanks for commenting on this thread (sorry for the delay)


I understood what you wrote... I was just commenting about how you said:

...seemed like a 1 minute FlashRenamer to an 8 minute Opus comparison. But as I explained, the two programs are doing very different things.

In any case, Leo made the same suggestion as I did - which is to consider not using context menu actions for operations on huge numbers of files, and instead use toolbar buttons or hotkeys, which will get around your 8 minute wait time and give much, much faster results.

Okay, I understand. Thing is that maybe a number of context menu items are not directly suitable for yet another button. In this case my intention was to run a 3rd party tool (Attribute Changer). Also, normally it is all working well and tfore actually there is no need for a button. Only in this exceptional case...
Anyway, thanks for the input.


It's your choice of course - but there aren't many things you CAN'T turn into a button... for example, if you're talking about Attribute Changer, then this works fine as a button (though you should probably keep it under a menu button rather than the top level of a toolbar): FileType CONTEXTFORCE CONTEXTMENU {D3F9A525-8824-497A-BE36-B23E22F141FC}.

That is the CLSID of the latest version (v8.20) of Attribute Changer's shell extension, which is the exact same thing that the context menu uses to show you the AC actions on right click.

Thanks Steje.
I have to confess...
frankly, am a bit embarrassed to say that I am unsure* how to proceed to get the thing you are suggesting.
No doubt it is a good suggestion, but what to do where.
(*unsure = haven't the faintest idea :wink: )


The command I posted above can simply be added to a toolbar button (and again, I recommend putting the button under a menu rather than directly on the toolbar)?

Like so:

<?xml version="1.0"?> <button backcol="none" display="both" label_pos="right" textcol="none" type="menu"> <label>Attribute Changer</label> <icon1>#setattr</icon1> <button backcol="none" display="both" textcol="none"> <label>Attribute Changer</label> <icon1>#setattr</icon1> <function type="normal"> <instruction>FileType CONTEXTFORCE CONTEXTMENU {D3F9A525-8824-497A-BE36-B23E22F141FC}</instruction> </function> </button> </button>