Correct, it happens on exit. Wont implement suggestion as want everything available after a crash, so that logs can be generated correctly and root cause analysed.
I hear you and understand. That is also a very developer-centric vs customer-centric stance.
I'll mark as solved but hope that you will consider a middle way approach. Something like,
init
if ClearListOnExit and DisplayDirty
then QueryClearOrPreserve.DefaultPreserveWith10SecTimeout
That would give us an opportunity to clear the display at startup. Otherwise, we have to wait for the startup to complete (takes a few minutes), stop processing (takes another few minutes) to exit, restart (takes another few minutes). This process can easily take 5+ minutes just to clear the display!!!
Alternative solution: Add a button to the Home Dashboard to clear the display anytime. After hitting the button only active items that are actively updating reappear on the list. That would be SUPER helpful! In fact, I would prefer this option. Thanks for considering.
Think you are after Ctrl-R (Menu > Remove). That clears without removing any files.
Close but not quite. Without multi-select this is not a viable option for a large list.
Also, Ctrl-R doesn't work. It only works via Menu | Remove.
If you can implement multi-select on the page (and Ctrl-R enabled), yes, that would work. Thanks!
Interesting observation. I just rebooted my system, and both multi-select and Ctrl-R work now.
The observed behavior atm is that after JMR has become unstable multi-select and Ctrl-R no longer work even after stopping / restarting the executable. I'll confirm that it's reproducible next time JMR gets into a funky state.
Just a quick update that improper keyboard / mouse handling continues after JMR has become unstable.
Are you using the latest beta which is 2022.0.15?
Support Migration
If JMR ends abnormally (or perhaps under other conditions - have seen it but can't characterize the conditions), the Clear List on Exit setting is not honored. It would appear that the Clear on Exit HAS to execute at JMR shutdown; thus, if something inhibits proper shutdown the setting is ineffective next start.
Suggestion: Instead, JMR should check this setting at startup and clear the list then, thus ensuring it is honored 100% of the time regardless of prior shutdown condition.
--- Import ---
Author: w73ad2e8vias
Created At: 2022-01-03T13:29:34+08:00
Updated At: 2022-05-20T20:42:49+08:00
Views: 10
Votes: 0
--- Import ---