Hallelujah... someone other than me .
[quote="GazChap"]I've had situations where I've been browsing through folders with navigation lock turned on, have lost the synchronisation, and even changed to an entirely different folder in an attempt to get synchronisation back.
It seems a little buggy, and more intrusive too.[/quote]
So, what you're seeing is what "I" have attributed to changes made in Opus 10 to try and be more intelligent about putting you back in either the first or last known in-sync position once sync is lost... and that's a worthy objective on the part of Opus.
However it's actually quite maddening when you "intentionally" go out-of-sync (say - in order to get some files or folders from someplace else that has nothing to do with my sync'ed navigation activity) but after which you want to go back to where you were last in-sync. In v9, if you DID go out-of-sync... as soon as you navigated your way around and clicked on a foldername that also existed in the other file display - you'd automatically go back in-sync without having to TELL Opus to explictly do so (via the "reset the sync position" link in the well-intentioned but oh-so-intrusive dialog box that shifts the display down a few rows - more on that below).
Also, in cases if you have MULTIPLE folder tabs on one of side of the dual-display - each of which perhaps contains a different "subset" of folders that are otherwise ALL commonly located in a single folder tab on the 'other' file display - switching tabs, then navigating to one of the folders located in your 'second' tab, but not in your 'first' causes you to go out-of-sync. Hitting the back button at this point then changes the 'second' folder tab to the folder path that the 'first' folder tab was opened to... clearly that's just plain wrong. But again, I think it's evidence of Opus trying to get you back to what it knew was an in-sync position.
Those are specific sorts of workflow scenarios I find myself in VERY often that I guess others do not - but in ANY case, my own feedback to GPSoft has been that any sort of folder action that Opus takes on it's own in order to try and re-establish sync AFTER going out-of-sync should be an optional setting. At least then - for whomever these changes are working out ok for - they can keep them; and for those of us who think Opus should just sit back and watch, we can kindly ask it to do so.
I welcome another voice on this - as the v10 behavior has unfortunately caused me to abandon Navlock for situations where I have lots of folder changes and do alot of transient out-of-sync navigation... in SOME of those cases, I've resorted to using my last v9 config from USB... but that's just a shame I have to do that - and I can't even rely on that for all cases since some of my workflows are related to things I've started using Libraries quite a bit for.
After alot of what I'm sure just came across as complaining (;-)) I just recently suggested the same thing if an option to re-enable the flashing File Display Border just wasn't something they could stomach... you'd still lose some visibility of files... but it wouldn't be any MORE loss of visbility than is currently the case - and it would NOT SHIFT the file display up and down. Somehow, I don't think I've managed to convince them that this is just totally intrusive, moreso than in any other situation in the application where this new non-modal message box appears - because it interferes with the sole purpose for which you're using Navlock... "navigating". Personally, I'd rather have the old flashing FDB. I guess some people were confused and didn't know what it meant... but I personally would have responded to such people with "RTFM" instead of implementing a method that was even 'marginally' intrusive to folder navigation.
For your other observations about the Rename dialog - it's best to open another thread for that as it's not specific to Navlock... Or, since it seems like it's a pretty straight case of un-desired behavior that could/should be "fixed", maybe just open a support ticket through the GPSoft website. I doubt there's much of a sensible "workaround" to what you're seeing there.