XYplorer Beta Club

I clear a handful of list mgmt dialogs on a regular basis. And it always takes quite some clicks, to call them up, then enter Edit mode, then select everything from below
-----> mru
to the end, then press delete, then grab the mouse again to click OK and to repeat the same procedure with the lext list.

It would ease maintenance chores to automate this. Don't know if anyone else ever wanted this feature. Maybe there already is a script and I could not find it. Recommendations are welcome.

so this is the script you want?

Thanks Sammay,
yes, this pretty much nails it. Except for it should not work on ALL lists. I want to keep things like PowerFilter and PFA.

Been trying my hands on ahk - inspired by your favfolder script which seems to emulate key presses. I got as far as running Ctrl R and entering the code for the first list I want to clear. F6 also worked, got me into Edit mode. But then realized I cannot simply arrow down and select down, because ---->mru changes positions. A visit to the ahk forum turned out intimidating, I gave up, lack of time.

hold on.

This is a radioactive solution. You've been warned. If you stray from the directions...

• Here's a helper script. Save it as an xys file in <xyscripts>. The script file's full path must not contain any single quote: ' Do not execute this script manually.

  _listmgmtcleaner_piped.xys

  [updated]

  (2.91 KiB) Downloaded 198 times

• This is the main script. Use this scriptlet to open a desired list mgmt dialog and clean it.

  Code: Select all

  ::$waitperiod='6000';run """<xy>"" ""<xydata>"" /fresh /win=min /script=""::perm $hwnd=<hwnd>;perm $wait='$waitperiod';load '<xyscripts>\_listmgmtcleaner_piped.xys',,f;""";#632;

  • there are a couple or three things to configure here. At the very end is the commandID for the list mgmt dialog you need to open. (#638 is Recently Opened Files.)
    Change this part for each dialog and exec this script again and again. I provide a list at the end of post.
    Note that only those dialogs that contain an Edit (pencil) button can be used. (And those where -----> mru notation is useable)
  • Right after the dialog opens it will go out of focus (because another XY window will open hidden, and steal focus). You'll have to click on the dialog and bring it back to focus within the period of time set as $waitperiod in msecs. I've put it as 6 seconds so that you can get used to the directions, then lower it to whatever you're comfortable with.
  • obviously make sure the xys file path conform to reality.

• How to use:
• Change the commandID to a desired one, change $waitperiod if needed and run the scriptlet. Not the attached script.
• The desired list mgmt dialog should open, but quickly go out of focus. You should notice this by the usual dimming of window shadow, or change of window titlebar color etc.
  At this point quickly click on the dialog (say, the titlebar) to bring it back into focus. Alt+tab can also work, but ensure the window did indeed catch focus.
• The script should do it's magic now. Afterwards, check if the result is OK and press OK.

If the script fails for some reason, wait a second or two or 3 or 4 or 5 (depending on the size of entries in the list dialog) before closing it.
Why? the script sends keypresses blindly and doesn't know whether they're being received by this list or by the Filelist.

These lists have a edit button and mru capability. Not sure about the last one

btw, I see now the FavFolderGUI project could've been entirely XYscripted using this method of sending keys from another XY instance!

Whoa - scary
Took your warnings seriously. Good thing I work portable, plenty of backups all over the place.
I ran it on VisualFilters #624
I got -----> mru in there - so basically all conditions are met - I also have multiple instances enabled to allow the second instance to work its magic. List dialog comes up, fingers are drumming .... and drumming .... still holding my horses ... but nope, the cleaning fairy does not seem to take over. I cancel out (also tried OK-ing out), call up the dialog again to check up on it - nope, still messy as it was before.

There seems to be some kind of action going on in the background, but I never lose focus of the list

Stef123 wrote:There seems to be some kind of action going on in the background, but I never lose focus of the list

Click the list anyways (within $waitperiod time) .
ed. since $waitperiod is 6 seconds, click at about 2-4seconds.
ed2. in fact, clicking anywhere on the main XY window (even though it's blocked) should do.
ed3. the foolproof method is apparently to keep clicking the main XY window, starting from right after the list dlg opens.

Got it. Had to switch to my private machine, there's some weird focus stuff going on with the other one.
It may not be the smoothest of all automated tasks, but it still beats doing it manually.

Now, how do I daisy-chain this thing, to get one list after another? Is it safe to copy and paste them back to back? Or could this spell disaster when it rushes through without actually waiting for each one to finish?

Sure, try something like this: plus to automate the final OKaying, uncomment these lines (there are two) in _listmgmtcleaner_piped.xys You still need to remember doing the clickity-click everytime a new dialog opens.

btw, there's another thing, the active XY instance should not have permanent variables called $hwnd and $waitperiod already defined (Scripting > Perm variables...)

Thanks
Glad you're open to weird inquiries. I am not the only one, though, someone else requested something like this just recently.

Works good enough for me now. 3 seconds give me plenty of time to click. It's a bit like supervising someone running your chores, who can't be trusted completely, so you prod him with a go-ahead whenever he falters.

The final OK-ing does not work. Commented out those 2 lines, and also waited a good while, but it never dares to make this final decision. No problem, though.

At one time I got a scripting error, don't know what went wrong. Clicking Continue was not possible, nor clicking anything else on the dialog. Turned out later those 8 instances were still running in the background, had to shoot them down with task manager. Never happened again, so I don't worry.

Many thanks Sammay

Glad to help unhelpfully.
See, you've experwinced first hand just how unstable it is!

Stef123 wrote: Commented out those 2 lines,

You mean you removed the // 'es ?

At one time I got a scripting error, don't know what went wrong. Clicking Continue was not possible, nor clicking anything else on the dialog. Turned out later those 8 instances were still running in the background, had to shoot them down with task manager. Never happened again, so I don't worry.

If this happens again, alt-tab into that other instance(s), it's main window might not appear, but it's error dialog should become clickable. Close it. Repeat.

SammaySarkar wrote:You mean you removed the // 'es ?

Yes. And saved it. So you're saying it works for you? Will try on other equipment, atm I am on this crazy machine that keeps stealing the focus away from me.
Thanks for the Alt-Tab - it didn't occur to me because the error dialog was right there, in front of me. Must remember this.

It works flawlessly for me! but I haven't tested it much!

After the cleaning is done, does the dialog go back to list mode (that is, not-edit mode) ?

I noticed the second "press-Enter" code doesn't have any wait before it.
So find the second [//copydata $hwnd, "::sendkeys ""{Enter}""", 1;] you'd uncommented and add this before it: What happens?