It will crash immediately.
I haven't been able to reproduce this.
If you have crash dumps, please email them to leo@gpsoft.com.au
[quote="leo"]I haven't been able to reproduce this.
If you have crash dumps, please email them to leo@gpsoft.com.au[/quote]
I emailed it to your email address and place it here too.
dopus.20151114.215824.zip (22.1 KB)
Thank you for sending the dump file.
Unfortunately, I was't able to work out what was going wrong from that one, but others may help if you can create them, especially if they can be created with the newer beta.
If the problem still happens with 11.16.2 (beta), please generate a couple of crash dumps with it and send those if possible.
dopus.20151118.154521.zip (23 KB)
Here is the dump file in 11.16 beta2.
The tab group loading is too slow now, it should be faster.
Thanks for the dump file!
It has revealed a bit but what's happening still isn't clear.
It looks like there is something wrong with your Windows 7 install. This is what the debugger reports for two fundamental Windows DLLs:
[ul][li]user32.dll 6.01.7600.16384 11/Jul/2009 08:26[/li]
[li]kernel32.dll 6.1.7601.18847 (win7sp1_gdr.150508-1512) 09/May/2015 03:24[/li][/ul]
Checking on my own Windows 7 virtual machine (which I last updated a month ago):
[ul][li]user32.dll 6.1.7601.17514 (win7sp1_rtm.101119-1850) 20/Nov/2010 13:15[/li]
[li]kernel32.dll 6.1.7601.19018 (win7sp1_gdr.150928-1507) 29/Sep/2015 03:08[/li][/ul]
It's not just that the DLLs aren't the latest versions for Windows 7. It looks like some of your Windows 7 install is the 7600 initial release version, and some of it is the 7601 service pack one release. That mismatch does not look right.
The debugging tools also cannot download symbols for that version user32.dll (possibly because it's no longer supported by Microsoft, although I am not sure), which severely limits the context I can see from the crash dumps.
Anything strange you're seeing on the system may be a result of the mismatched components, and I suggest getting that fixed. sfc /scannow from an Administrator command prompt may be able to repair the Windows install, but it will depend on how it has gone wrong.
Going back to Opus, loading folder tabs should only take as long as it takes to load the directory listings. Unless the folders are extremely huge (e.g. 80,000 files), on slow/unreachable network drives, or on drives which have spun down and take time to wake up, there would not normally be enough time to close a window before they had loaded. Still, I have tried with some very large folders and haven't been able to get a crash. I've also tried programatically closing the window immediately after the load begins, without any issues.
From where the crash points in the code, it is very early in the tab-loading process, before the directory listing has even been read, so something unusual is causing a slowdown if you have time to close the window before the code has gone past that point. The mismatched Windows DLLs could well be the cause (and should be fixed first anyway), but it could also be other things. Check that no folder tabs, toolbar commands or toolbar icons point to unreachable network drives as they can cause long delays in unexpected places.