XYplorer Beta Club

Hi,

Update 17.07.2019:
- Added v0.9.8 release

Latest changelog:

******************************************************************************
@Changelog:
v0.9.8:
+ Added a pattern to recognize "*.rar.<3 digit incrementing number>" files

v0.9.7:
* Fixed a bug with CleanUpFolder = true when the destination folder contains not only one subfolder
but at least one additional file
* New icon by courtesy of kunkel321

v0.9.6:
* Fixed the GUI bug that files aren't visible when DstInactivePane=1
* Fixed a bug for destination folder cleanup when CleanUpFolder=1
* Minor changes to the xy script

******************************************************************************

Download current version: Download older versions(s) Old Downloads: 324

Description:
Here is one of my scripts that I use on a daily basis.

It extracts single / multiple (selected) archives into one or multiple folders (based on your selection and user input), cleans up the remainings and deletes the archives afterwards. The whole process is now separated from XYplorer so you can now minimize, switch tabs or even quit it while Extractor is still able to finish it's work.

Supported archive tools:
7-Zip (http://7-zip.org/) - GUI / CLI versions
Bandizip (http://www.bandicam.com/bandizip/)*
ExtractNow (http://www.extractnow.com/)
FreeArc (http://freearc.org/)
PACL (http://www.powerarchiver.com/de/powerar ... ne-pacl-2/)
WinRAR (http://www.rarlab.com/)
WinZip (http://www.winzip.com/)

*Bandizip isn't able to overwrite existing files without asking for permissions.

Options (must be set inside the .ini configuration file):
- CleanUpFolder (default=1): You can choose if you want the script to move a single folder (only if it is the only one inside the destination folder) one level up and rename it accordingly

Example: An archive (let's call it: "In the mood.zip") contains only one folder named "Music" with several subfolders / files. Let's assume we're on drive "E:\" in the "Temp" folder and extract this archive.

The result would look like this: I don't like such archives / structures so the script changes this to: - DeleteArchives (default=1): If you select one or more archive file(s) (in the active pane) all files will be deleted after the extraction process. The recycle bin is used so if the OS doesn't try to delete it from there by itself because of filesize restrictions you will still be able to use the "undo" feature of XY to get them back. XYplorer's undo will only be available when it's window is the active one when Extractor has finished it's work (otherwise it will silently put all deleted files into the recycle bin).

- DstInactivePane (default=0): By default (value = 0) the current path of the selected archive is used to extract it. If you set it to 1 the path of the inactive pane is used instead. Be careful, if dual pane is not active, it still uses the inactive pane even if it isn't visible!

If you decide not to delete any files you can close this window by:
Press "Esc"
Press "Alt + c"
Click the cancel button

If you want to select / deselect all files:
Right click in the listview to get the context menu
Click the toggle checkmark in the bottom right corner
Press "Alt + t"

The attachment contains Extractor.ahk, Extractor.ico, Extractor.exe (already compiled) and Extractor.ini.

Currently supported archive types are:
Single part archives:
- .zip & .rar (classic)

Multipart archives:
- .001 | .7z.<digit(s)> (7z format)
- .zip | .z01 | .z<digit(s)> (old zip format)
- .zipx | .zx01 | .zx<digit(s)> (new zip format)
- .rar | .r<digit(s)> (old rar format)
- part1.rar | part<digit(s)>.rar (new rar format)
- .rar.001 (rar format)

Depending on the used application:
- .ace
- .cab
- .gz | .tar | .tar.gz | .tgz
- .img | .iso | .vhd | .wim
etc.

Usage:
Copy the Extractor.exe and Extractor.ini to any directory you like.
E.g.: "<xypath>\Tools\Extractor"

Use this little script to invoke Extractor.exe (ofc you have to select one or multiple supported archive files before):
>= v0.9.5 < v0.9.5 Don't forget to edit the path if you need to.

Open "Extractor.ini" and change the "Application" key in the [General] section to one of the titles of the other sections.
E.g.: or Additionally you can edit:
- CleanUpFolder to "1" (for true) or "0" (for false)
- DeleteArchives to "1" or "0"
- DstInactivePane to "1" or "0"

If Extractor.exe can't find the application because of a different path on your system it'll ask for the necessary .exe and stores it back into the .ini file.
Don't change ExtractArgs1 or ExtractArgs2 keys otherwise you'll break the script.
You can delete any section (apart from the [General]) that you don't need / don't use.
E.g.: If you only work with WinRAR you are free to use only the following .ini file content:
If you have a multipart archive and you want to extract it into one folder, please select ONLY THE FIRST (STARTING) file from that archive!. The script will guess all other files automatically that belong to this archive. If you select more than one file the script will ask you if you want to extract them into one common folder or into separated ones.

The old version (a .xys script) is gone. It makes no sense to use scripting in this case while VBScript doesn't support threading (or at least: XYplorer doesn't support it within scripting)

Since v0.9.4 relative paths are supported (at least ".\" or (a combination of) "..\").
These paths are relative to the folder in which Extractor.exe is stored!
If you experience any errors or if you have any suggestions, post them in this thread.

<Reserved>

Changelogs or anything else...

I registered for this forum in order to inquire whether the developer of Xyplorer would have any interest in taking over development of Locate32, which is a fine desktop search program. The developer of locate32 posted today that he basically does not intend to further develop it. I use both Xyplorer and Locate32 and otherwise have no affiliation with either.

steward00 wrote:I registered for this forum in order to inquire whether the developer of Xyplorer would have any interest in taking over development of Locate32, which is a fine desktop search program. The developer of locate32 posted today that he basically does not intend to further develop it. I use both Xyplorer and Locate32 and otherwise have no affiliation with either.

Thanks, but no time. Not a second.

Update 14.08.2013:
- Completely rewritten
- Additional support for 7-Zip and ExtractNow (ExtractNow is now the default application)
- Much more sanity checks
- Use of status line to provide more feedback
- Various other small changes / fixes

Hi highend,

I hope all is well.

Very nice script except I'm experiencing an issue. I ran it a couple of archives (zips). It made the appropriate folders for the archive contents and the contents were extracted to the folders with no user intervention, but after that I received this message. I wasn't able to minimize XY, because as the message says, the script was running. I pressed the OK button on the message and tried to minimize and received the same message. This happened a number of times. However, after hitting OK, I was able to close XYplorer and all was fine. I then ran it again on another archive and the same thing happened. Running Windows 7 (x64).

Thanks,
Ken

Hi again highend,

I think I've solved the mystery message. I forgot that I purposely didn't write over an existing "checkprocess.exe" file in my xy scripts folder, that I had and was still using in a different script. When I put the new "checkprocess.exe" file that you delivered in the extractor.zip, no more messages. When using the other version of checkprocess.exe, I had checked Task Manager, and there was "5" running instances of checkprocess.exe. No wonder I received that message.

OK all is well with that issue, however, I stumbled across something else. I have "false" set for both CleanUpFolder and DeleteArchives in the ini file. When the script's done making the folder and extracting files to it, I get the "These files will be deleted" check box asking if I want to delete the archive, I uncheck the box next to the archive and it still deletes the archive (both a zip and a rar example). Either checked or unchecked and it deletes the archive, but why would/should it ask if we have "false" set in the "ini" file. If "false" is set, I would think the default on the check box, if it displays at all, would be unchecked. I'm using WinRAR by the way.

I may have to modify the ini file to rename the checkprocess.exe file if I experience an issue with running the other script that uses the different version of checkprocess.

Thanks,
Ken

Hi Ken,

thanks for your feedback.

I've did a few tests to see if CheckProcess.exe fails during a script run but so far no luck
The only thing that could confuse it is: if a new instance of winrar is opened while the script is still running.

A better way would be to check for the PID instead of a taskname but there is no way to let CheckProcess know with which PID the packer application starts (because XY doesn't support that).

The only thing that could work as well (to make CheckProcess a bit more foolproof) is when it looks at the parent process of the packer. Process Explorer can show this information but I didn't had the time to see if I can get this info via AutoIt. In case if isn't possible but AutoHotkey would be able to do that I'll change the script language for it.

Btw, I didn't touch the .au3 code for over 1,5 years so you probably didn't get a new version of CheckProcess from the download.
doesn't fail but the delete command worked on the selected files because $filesToDelete was empty. That's the reason why the files got deleted even if you deselected them in the dialog window.

Replace that line with: to get rid of this bug.

Regards,
Highend

I'm not sure what was going on with checkprocess, but the other version certainly wasn't closing because there were 5 of them showing in TaskManager. It definitely was a different version. The raw byte size was quite a bit different (665353 your latest included in the zip and the old one is 682505). I remember we chatted on checkprocess 1 year or 2 ago. Remember this thread http://www.xyplorer.com/xyfc/viewtopic. ... ess#p74875 One version used the clipboard, the other a temp file. I don't think I compiled anything myself in autoit since I use AHK.

The tweak you provided did the trick. I unchecked the archive file and it was not deleted. Though, why should the inputselect box need to come up at all, if you want to keep all archives and have the ini file set not to delete archives (i.e., unless I'm missing something, if DeleteArchives=false, why show that inputselect box at all)? It would save us having to deal with that box at all.

Thanks again,
Ken

Yeah, there was a former version of CheckProcess that used the clipboard instead of a file. Though it's been a very long time since I changed that. You could decompile your old version to see any differences *g*

I'm working on a new CheckProcess, this time it's written in AHK. It uses a wmi query to get a list of processes with names, creationdate, processid and parentprocessid.

I'll check if the packer application has XYplorer as it's parent process and if it was started after XYplorer (so it really belongs to that process).

Hopefully this will solve any "ghost" processes of CheckProcess. Should be ready on friday.

(i.e., unless I'm missing something, if DeleteArchives=false, why show that inputselect box at all)?

It shouldn't
Using "true" | "false" in an .ini file isn't a good thing. I'll switch to "0" | "1". "false" isn't evaluated as 0 but as a normal string and because of that the check for $deleteArchives fails.

Please use
DeleteArchives=0

and it'll work correctly. I'll make a note and update the script tomorrow / on friday.

I changed the false to "0" and that did indeed eliminate "These files will be deleted" inputselect box.

I noticed a quick flash come up on the screen as it runs. Is that the "checkprocess" or the run for WinRAR in my case? By the way and if I remember correctly, wasn't the whole idea for us using checkprocess was to have a way to detect when the running program completed and then be able to continue the script or operation. Can't you now use the "run" command with the relatively new switches, the wait parameter of 2 - wait til its done without a message box, and a show parameter of "0" to not show the running program. I know in some of my cases I've tried, they don't always work.

I noticed a quick flash come up on the screen as it runs

Mh, not on my system.

Can't you now use the "run" command with the relatively new switches, the wait parameter of 2 - wait til its done without a message box, and a show parameter of "0" to not show the running program.

The help file states that it can be unreliable (for unknown reasons) so I don't know if it's a good idea to switch.

I'm currently thinking about using copydata to communicate with CheckProcess so that only one instance would be enough to handle all extractions (it isn't so easy to pass new command parameters to an .ahk exe when it's not started for the first time). Mh...

Btw, do you really never get the "A script is currently running" message (when you try to minimize XY during extraction) while extracting a large archive when using the old .au3 compiled CheckProcess.exe?

Remark: Using run with ..., , 2; will always display it.

highend wrote:Btw, do you really never get the "A script is currently running" message (when you try to minimize XY during extraction) while extracting a large archive when using the old .au3 compiled CheckProcess.exe?

I've been using the checkprocess that came in the zip. As it turns out I was no longer needing or using the old version since I stated using AHK.

I received this message however, when running extractor on my laptop. It still worked and extracted as it should. Note: I made all the changes we discussed above (i.e., using "0" instead of false and changing the line "if (($filesToDelete != ..." line in extractor.xys.

Concerning the flash that takes place, I still see a very quick flash. Could that be the message, "A script is currently running", I have an SSD, so the extraction even for many files happens extremely fast. Though it sounds like I'm only suppose to see it if I try to do something, like minimize, during the process. I haven't looked at the script in detail to know what is happening...yet.

highend wrote:Remark: Using run with ..., , 2; will always display it.

Wait parameter "2" from Help is:

2: Wait, no message: Same as above (parameter"1"), but without message box.

And the show parameter "0" is:

0: Hides the window.

By the way, I've been using AVI's ClipJump since he initially wrote it. I find it to be excellent. I used it 4 or 5 times writing this post.
Thanks,
Ken

Hey highend,
Another follow-up. I'm not sure if you use WinRAR or one of the other archivers, but in running extractor with a big archive it became obvious to me that the window that literally flashes on the screen is WinRAR. So, I looked at the WinRAR's command switches in the help file (quite an extensive list). There is one switch for running WinRAR in the background "-ibck". I added it to the extractor.ini file for WinRAR's ExtractArgs1 settings, and no more flashing as shown here:Fast and seamless now using WinRaR.
Thanks for the nice script,
Ken

I received this message however, when running extractor on my laptop.

http://www.xyplorer.com/xyfc/viewtopic. ... +recursive

The tweak should avoid behaviour.

Wait parameter "2" from Help is:

You misunderstood me This comment meant that the "A script is currently running" message will always appear. It wasn't a comment about the parameters for the run() command.

By the way, I've been using AVI's ClipJump since he initially wrote it. I find it to be excellent.

It's an interesting way to control an application just by not releasing a modifier key. The only thing that really annoys me is that it's storing duplicates of already copied items That "pollutes" the clip and history cache...

There is one switch for running WinRAR in the background "-ibck".

Thanks. I'll have to try that. I'm using ExtractNow atm, because it's fully portable and it has a minor advantage over Winrar: it's able to extract multiple archives to different directories with a single command line. All other supported packers need a foreach loop instead.

Regarding the implementation of a new AHK CheckProcess: It'll take much longer than I thought. I have to find a proper solution for a few things when I don't want to start more than one process of it or use the copydata to exchange information. More difficult than I thought originally...