276
Support and Feedback / Re: BUG: MultiCommander.xml gets corrupted
« on: November 29, 2024, 12:04:39 »
I'm not able to reproduce that. Did you do any other changes during that ?
MultiCommander v14.2 is released!
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
The heading pretty much says it all:Hmm Subject is not a body. Reason there are two fields hehe
Jungle, my new hero and world savior!
Yes, thank you!
Mathias, may I change the wish to getting a search / filter function for all the settings, some day in the future.That would be great. Some other file managers actually have that.
start shell:AppsFolder\48089MathiasSvensson.MultiCommander_9d7x1c4ybj2dr!MultiCommander -AutoRun=_UDC_runAt_MC_Startup
Nope. But I think I could now reproduce it:That is another thing.. Most column properties are cached. so you might need to F2/F5 to refresh.
When I inline rename a file (Windows Style F2), the path length is not updated automatically.
I have to manually refresh in order for the path length to update.
Thanks for the 3038 update & fixing the file sizes output/updating Mathias!I will check, It started in 3038 ? 3036 was fine ?
However I have found a problem with this build I think.
F6, drag'n'drop & my buttons now hang on dialog & that also impacts the queue process.
Where I use a button + User Defined Command in my move operations the dialog now hangs for as long as I leave it @0%.
i.e. User Defined CommandsCode: [Select]MC.Explorer.Move NODIALOG USEEXISTINGQUEUE
This seems to be related to the delete phase when a single item is moved as it shows the progress bar but hangs on open, folder+file(s) move is less likely to behave at all.
Hi Mathias, yes was fine in the 3036 build (I just had the size update issue)
& I just added above - "I notice the move op done via Win ctrl-X / ctrl-V leaves a 'ghost' file & size value in the folder." in case you missed it