I have found a bug. When you open file properties dialogue, it and it's child dialogues (e.g. file security settings) will stay on top of all other currently opened windows. This is very inconvinient.
Not only file properties dialogues do this. When you open a menu on a toolbar while in customization mode, the menu will also stay on top. The same applys to Command Editor dialogues, they also stays on top. So when you want to open Help (doesn't matter whether is it in browser or in chm file), it will be overlapsed by these windows, which is also inconvinient.
We're thinking about changing the command editors. The problem is that pop-up menus are inherently on-top, so the things that edit them need to be as well, unless we do something about the menus.
I think it's because they don't have taskbar buttons, so it's easy to lose them behind other windows if they aren't on-top, and they are almost never things you leave open unless you're still looking at them.
(They've been that way for so long, 10 years or more, that the exact reasoning is lost to time, but I suspect it's that.)
They have taskbar buttons, at least in all Windows versions, starting from XP. Also they don't stay on top, if they are opened from Explorer.
In my use case, I have file property extension called HashTab, that is used to calculate file hashes. It has drag and drop capabilities to compare hashes of two files, so I need to open file properties dialogue, then switch back to lister, navigate and select other file and drag and drop it to HashTab in file properties dialogue. The problem is, that this dialogue overlaps lister. This is especially annoying on a small laptop screen.
They don't really. The taskbar button happens because Explorer launches them via a separate .exe/process which itself has a taskbar button. (It's also a generic icon in Windows 10, so it looks like it's actually a bug, or someone forgot to ever make an icon for it.)
The API for displaying a properties dialog does not give the dialog an icon on the taskbar.
It's possible we could create a hidden parent window which acts as the taskbar icon, and show the dialog when it is clicked, but would take some work and experimentation. If more people ask for it we'll certainly look into it.
Comparing hashes can be done in other ways, FWIW. There's even a script on the forum for doing it, although I prefer to use a diff tool to compare files (Beyond Compare and other diff tools can integrate well with Opus, and you just select the two files you want to compare and click a button, without any multi-step setup process between multiple windows).
Thank you for explanation. In XP they don't have taskbar buttons indeed, I checked now in vm. In Windows 7 they have them by the way. Also they have buttons, when opened from DO, and buttons have propper file icons.
Although, trying in Explorer now, it seems better than the last time I looked. They have proper icons there, and the window is associated with Explorer and stacked with its other windows instead of being off in its own group. Looks like Microsoft fixed that bug recently.
But no icons for them in Opus in Win10. Maybe Win7 worked differently and they changed it again afterwards. (The current on-top code/design dates back to XP or possibly even earlier and Win98.)
It seems like the API in Windows 10 works the same now, much to my surprise. Something may have changed recently, or I just hadn't noticed (and the bugs in Explorer in Win10 made me assume the API itself was still the problem).