ZIP UDF (zipfldr.dll library)

[BrewManNH]

BrewManNH: Ah. So now you are saying "If I put it in the documentation - I don't have to fix it". Er....no? I can put in my documentation "I don't pay income taxes" but I don't think the IRS will let me do that.

Stupid analogies are stupid. If YOU know that the function you're trying to use, any function it doesn't matter which one, doesn't accept the data you're sending it in the format that you're sending it, then it is up to YOU to fix that because that is how it works. Just because it can be fixed to accomodate incorrectly formatted data doesn't make it incumbent upon the author to fix it so that you can send it incorrectly formatted data. You can always modify the function to accept your data in Klingon, but I don't think that the author of the function is required to accept Klingon as valid data.

Or to put that another way - just because you KNOW there's a problem and SAY there's a problem - it doesn't absolve you of trying to remove such problems.

It's not a problem, it's a limitation, there's a vast difference. It's only a problem if he stated that it would accept the path with forward slashes, he acknowledged that it didn't because that's how he programmed it but he didn't say it was a problem per se, just that it was not how it worked.

A flat, outright, denial of allowing any updates is an extreme. But a total acceptance of anything given to you is an extreme as well. You have to have a happy medium where you look at, consider, and if the changes do improve the product without harming it, you use them. I also want to point out the obvious. I am very sure your mom - at some point in time - has said you something like this: "If everyone else jumped off of a cliff - would you jump too?" To show you just how dumb it is to follow the crowd just because the crowd is doing something. The same holds true for AutoIt and the UDFs. If the rest of AutoIt just dumps on the usage of slash versus backslash - and you know it - should you be just like everyone else and not care a bit that this problem isn't handled properly? Or should you try to improve the product so - unlike everyone else - your product does work properly? Think about it. :-)

He's stated previously in this thread that he recommends using the 7Zip UDF because this one was supposed to be a novelty function. He's been updating it as problems, real problems, are pointed out to him. But it's not his job, as he stated above, to fix your errors for you. Fix them yourself and shut up about it already. You've already gone on far longer than it would have taken you to update the UDF yourself for absolutely no reason. Change the UDF to how you want it to work, use that modified version and move on, your blood pressure will thank you for it.

[Enigma]

1. The only stupid analogy is the one where you say you do not bear any responsibility for what you have put out there for others to use. Period.

2. You are mis-quoting his original post. (He may have changed it by now - but I haven't looked at it recently.) He did not say that was how he programmed it. He said "That is how it is under Microsoft Windows" and I pointed out that that is not true.

3. You continue to mis-quote me. I did not ask him to fix my errors. I asked him to fix his.

A secondary problem with the ZIP UDF which I have found at last is that his UDF assumes that when it opens a ZIP archive the count will always be larger than one(1). When it isn't it crashes the program because it is attempting to access a non-existent location. I shall assume that you believe this is not a problem with his UDF also and not pass on where the problem resides exactly I have corrected this in my copy. Now it no longer crashes on me for unknown reasons. Also, in looking across the internet for information on the various functions in the ZIP DLL, I came across an interesting PowerBasic set of examples on how to use the ZIP DLL. They show (in PowerBasic terms) how, when extracting files, you should wait for the extraction to complete before moving on to whatever it is you are wanting to do. By putting in that code the UDF now waits until all of the files have been extracted in the unzip/unzipAll routine before it returns to the calling program. I had noticed that every once in a while I'd get an error sent back to me for no apparent reason. The PowerBasic code takes care of that problem too.

So now I don't have to worry about "/", the routine crashing because of it attempting to use non-existent memory locations, and it properly waits for the unarchive to finish before returning to the calling program. If you want me to upload the new UDF - let me know. Otherwise I will take you at your word and move along now that I've fixed these problems.

Last - let me reiterate what I have said before - I really do appreciate all of the hard work people who make these things put into them. AutoIt would not be what it is today without all of that hard work and I would have had to call shell scripts to get this done without the UDF provided. So thank you to everyone who has made these things and who help those who need help.

Later! I will check back in a week and if the new UDF is wanted I'll upload it then.

[Enigma]

I have no idea what PM means but I can (I think I can) delete the enigma2 account. As I said - I simply do not have the password at work. If I can not get rid of the enigma2 account I will e-mail the AutoIt people via the contact us link and ask them to remove it. :-)

[Valik]

Enigma, stupid argument is stupid. wraithdu wrote the function so he can decide what input it accepts. If he decides to change it from accepting to the string "chicken" then that is his prerogative. If you don't like it then use another function. Personally I would support / delimited paths but he is not wrong for choosing not to with his own function.

As for the multiple accounts. Normally that is a permanent block. Im going to let you off rather easy and just give you a seven day ban instead. You aren't being malicious, just stupid. I suggest in the future you consider our rules as well as the rammifications your poor decisions have on people who are incredibly busy and would rather do other things than clean up your mess.

[wraithdu]

@Enigma

When you're back and if you still feel like contributing...

- I'd like some code example to reproduce the crash you're talking about.

- Please provide the link to the PowerBasic examples you're referring to and I'll take a look at them.

- You can PM (private message) me your copy of the UDF and I'll take a look at what you've done. If I want to incorporate any of your changes, I'll do that and give you credit in the headers.

If you care to detail anything additional or add more color to your changes (except the slash check, I think that issue is dead), that would be helpful.

[Tippex]

Please can the "_IsFullPath" function be fixed to allow server "\\" paths?

These additional lines are needed:

ElseIf StringInStr($sPath, "\\") Then

Return True

as shown below (thanks).

; #FUNCTION# ====================================================================================================

; Name...........: _IsFullPath

; Description....: Determines if a given path is a fully qualified path (well, roughly...)

; Syntax.........: _IsFullPath($sPath)

; Parameters.....: $sPath - Path to check

;

; Return values..: Success - True

; Failure - False

; Author.........: torels

; Modified.......:

; Remarks........:

; Related........:

; Link...........:

; Example........:

; ===============================================================================================================

Func _IsFullPath($sPath)

If StringInStr($sPath, ":\") Then

Return True

ElseIf StringInStr($sPath, "\\") Then

Return True

Else

Return False

EndIf

EndFunc ;==>_IsFullPath

[ivanjong]

i am getting an error on this udf,

F:ilauncher_Zip.au3 (134) : ==> Error in expression.:

Until IsObj($oNS.ParseName($sNameOnly))

Until IsObj(^ ERROR

with this in my autoit script

$tempzipfile = @ScriptDir&"ilaunchertemp.ilsave"

$ilaunchersetting = @ScriptDir&"ilaunchersave.ini"

_Zip_Create($tempzipfile, 1)

_Zip_AddItem($tempzipfile,$ilaunchersetting,"",1809) . anyone can please tell me how to fix this? i checked the error is from _zip.udf,

line 129 Local $oNS = _Zip_GetNameSpace($sZipFile, $sDestDir).

i checked _Zip_GetNameSpace($sZipFile, $sPath = "") function and it returned 0

Edited March 23, 2012 by ivanjong

[wraithdu]

$tempzipfile = @ScriptDir&"ilaunchertemp.ilsave"

Zip file must end in .zip. Not my limitation, it's the library.

[ivanjong]

ok then thanks

[Rinzwind]

Good idea to change _IsFullPath to support network locations.

Func _IsFullPath($sPath)

If StringInStr($sPath, ":") Or StringInStr($sPath, "")Then

Return True

Else

Return False

EndIf

EndFunc ;==>_IsFullPath

[Kyme]

i have an small issue,

it's there an function to add only the files from path?not the whole folder?

something like c:backup*.* instead c:backup

if i make an _zip_additem(@scriptdir&"backup.zip",C:backup)

the structure of zip will start with folder backup, can it be done to starts with content of that folder?

sorry for asking but really i don't see it

[wraithdu]

Asked and answered already. No, there is no function to recursively add files based on wildcards or folder contents, and it is not planned either.

Edited September 5, 2012 by wraithdu

[Digisoul]

Hello warithdu,

I am facing a little problem, I am trying to extract one file from Excel New format ".xlsx", but it always give error # 4 (ZIP file / item path does not exist).

If i change the ".xlsx" to ".zip" its work as expected, is there any solution to extract; Without renaming the Excel file?

[wraithdu]

Nope, it's a limitation of the zipfldr library, it won't operate on any extension other than .zip. Now, perhaps if you modified the file association in the registry to tell it that xlsx files are zip files... but then you've just broken office. Unless this is part of a script and you want to make that change just temporarily.... in the end I think it's easier to temporarily rename the file, or add the .zip extension then remove it, etc you get the idea.

Edited September 28, 2012 by wraithdu

[TheSaint]

Thanks wraithdu!

You've given me an idea for my Installer Creator packages, that I may take up. It hadn't occurred to me to do it that way.

So basically, if I tell the registry that a specific extension is a zip file, I can rename them to that appropriate unused extension.

[t0nZ]

Tested zip udf in two my scripts , and it works fine in windows 8, confirmed.

(My scripts only do basic zip & unzip of one single m$sql DB file.

Thanks for the good udf.

[wraithdu]

My pleasure! Finally someone found it useful

Edited October 8, 2012 by wraithdu

[jdelaney]

Just found this, works well. _Zip_ListAll doesn't return relative paths in zips, such as the root of the zip containing: "..folderfile.txt"...so when you unzip to C:something, it will instead be unzipped to C:folder.

I suppose this uses the same methods as the File Explorer, and these zip file contents are not viewable there, as well.

Edited March 13, 2013 by jdelaney

[ChuckNorrious]

How's the compression? is it comparable to 7zip?

[Chimaera]

Just tried using this on Win 8 and im getting an odd error

These are the files i have

and im using it like this

$aRarFile = _RecFileListToArray(@ScriptDir, "*.zip", 1, 0)
_ArrayDisplay($aRarFile, ".Zip Files")
If IsArray($aRarFile) Then
$FileEnd = StringTrimLeft(_ArrayToString($aRarFile), 2)
MsgBox(64,"test",$FileEnd)
_Zip_UnzipAll(@ScriptDir & "\" & $FileEnd, @ScriptDir)
EndIf

Is it capable for multi archives?

All i want to do is extract them into the same folder

I get the same error if i try this on its own

#include "_Zip.au3"

_Zip_UnzipAll(@ScriptDir & "\grab-the-dvd-art.zip" , @ScriptDir & "\Test")

Edited May 9, 2013 by Chimaera