|
I am missing the mfc components. Can anyone help ?
|
|
|
|
|
Thanks a lot Dan for writing this wrapper, actually we have used Gilles Volant's API in our code long ago and some times back we found an issue, thanks to you, through your wrapper I just compared and figured out the bug.
|
|
|
|
|
I Need To "VC9 Build X64" "X32" .
|
|
|
|
|
Can you please tell me how to compile and run code in devc++??
i compiled the code but it give me many errors..please explain how do i add header files and library in devcpp?
|
|
|
|
|
Hi, I built this in Visual Studio 2008, 64 bit release mode. Couldn't get unzip to work. Turns out that the CreateDirectory check is too harsh. If CreateDirectory fails, CUnzipper::CreateFolder returns false. But CreateDirectory can fail if the folder already exists, so a call to GetLastError is warranted.
if (!::CreateDirectory(szFolder, NULL)){
DWORD lastErr = GetLastError();
if ( lastErr != ERROR_ALREADY_EXISTS ) {
return false;
}
}
This seems to fix the unzip problem. Took me a day to figure that out - thought I'd save some of you the trouble.
|
|
|
|
|
|
|
Thank you very much.. your article helped me lot.
|
|
|
|
|
Awesome. It's nice to know that 10 year old code is still useful
|
|
|
|
|
Hi, all.
I am not quite familiar with the "Creative Common Attribution-ShareAlike 2.5 Generic" license, so I don't know whether it's OK to use this wrapper in commercial software.
Is it right that if I use it in commercial software, I must not change the code in it?
Thanks.
|
|
|
|
|
Yes, I give you full permission to use this code for _any_ purpose. And to modify it.
|
|
|
|
|
In two places, you check for a ":" to see if a path is relative or not. But that gave the wrong result on a UNC path, eg
\\Server\directory\file.txt
So, I changed PrepareSourcePath to:
void CZipper::PrepareSourcePath(LPTSTR szPath)
{
if (PathIsUNC (szPath))
return;
bool bFullPath = (strchr(szPath, ':') != NULL);
if (!bFullPath)
{
char szTemp[MAX_PATH];
lstrcpy(szTemp, szPath);
_makepath(szPath, NULL, m_szRootFolder, szTemp, NULL);
}
}
and changed CZipper::AddFileToZip similarly...
bool bFullPath = (strchr(szFilePath, ':') != NULL);
if (::PathIsUNC (szFilePath))
bFullPath = true;
I hope that helps others!
Iain.
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
|
|
|
|
|
This may not be the best way of fixing this but I solved the problem of making it all work in a Unicode app. by making the problem go away.
First of all, we had previously taken the Zipper/Unzipper and ZLib code and built it into a static library, so we're not quite starting from the same place. I am still building this as a MultiByte character set library and just using it in my Unicode app.
The problem then is that when the headers are included in your Unicode app. all the LPTSTR declarations change into LPWSTR and so on. Then your app. won't link because it can't find the LPWSTR versions of the functions in the library (as they don't exist).
So, all I've done is change Zipper and Unzipper so that all the LPCTSTR function parameters are LPCSTR and all the LPTSTR ones are LPSTR and rebuilt the library (still using the Multibyte character set). Now that these parameters are all explicitly chars, not TCHARs, everything works fine so long as when you call the functions in your Unicode app. you are sure to pass char strings to the functions and not TCHARs.
The important thing to be aware of is that there is no need to convert everything to Unicode in a Unicode app. If you explicitly use char, LPSTR, LPCSTR and CStringA and don't use _T() macros then everything is exactly as it is in an MBCS build, even if you are building for Unicode.
Also, this approach is, of course, no use to you if you need to add files with Unicode names into your zip files, or save the zip file with a Unicode name. But it's good enough for my purposes.
Regards
- Roger
|
|
|
|
|
I have gotten around the unicode problem (at least compiling) but when I try to create a zip file, and then add a file into it (not the same path) the code returns success but the file is not created. What am I doing wrong? The file names and paths are showing up correct in my log file, but no file is created. Here is the code:
if (zipme.OpenZip(szTempOutput, NULL, TRUE))
{
fnLogServerEvent(m_pConnect, L"zip open", szTempOutput);
if (zipme.AddFileToZip(strPathFile, true))
fnLogServerEvent(m_pConnect, L"zip success", strPathFile);
else
fnLogServerEvent(m_pConnect, L"zip not successful", strPathFile);
}
else
fnLogServerEvent(m_pConnect, L"zip open not successful", szTempOutput);
The string used in the OpenZip is the full path and name (c:\temp\a.zip) and the file to be zipped is the same way (c:\mydir\myfile.txt)
As I have been struggling with this, it seems that the problem lies in the zipOpen statement in Zipper.c - from what I have read this must be using an fopen which only works with char, not wchar_. I think that may be my problem - the file is not really opening, even though it does not give me an error. Any ideas how to remedy this?
|
|
|
|
|
I am getting the following erros in both the Unzipper and Zipper files (more errors than I have posted here but all the same basic error):
I am not a C guru. I am working in VS6. Any help is most welcome!
Unzipper.cpp
C:\ina\Source Codes\INABusinessObject\Unzipper.cpp(50) : error C2664: 'UnzipTo' : cannot convert parameter 1 from 'char [261]' to 'const unsigned short *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
C:\ina\Source Codes\INABusinessObject\Unzipper.cpp(100) : error C2664: 'GetFullPathNameW' : cannot convert parameter 3 from 'char [260]' to 'unsigned short *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
C:\ina\Source Codes\INABusinessObject\Unzipper.cpp(123) : error C2664: 'lstrcpyW' : cannot convert parameter 1 from 'char [261]' to 'unsigned short *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
C:\ina\Source Codes\INABusinessObject\Unzipper.cpp(160) : error C2440: '=' : cannot convert from 'char [261]' to 'const unsigned short *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
C:\ina\Source Codes\INABusinessObject\Unzipper.cpp(190) : error C2664: 'lstrcmpiW' : cannot convert parameter 2 from 'char *' to 'const unsigned short *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
C:\ina\Source Codes\INABusinessObject\Unzipper.cpp(222) : error C2664: 'lstrcmpiW' : cannot convert parameter 2 from 'char *' to 'const unsigned short *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
C:\ina\Source Codes\INABusinessObject\Unzipper.cpp(257) : error C2664: 'lstrlenW' : cannot convert parameter 1 from 'char [261]' to 'const unsigned short *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
C:\ina\Source Codes\INABusinessObject\Unzipper.cpp(277) : error C2440: '=' : cannot convert from 'char [261]' to 'const unsigned short *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
Zipper.cpp
C:\ina\Source Codes\INABusinessObject\Zipper.cpp(52) : error C2664: '_splitpath' : cannot convert parameter 1 from 'const unsigned short *' to 'const char *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
|
|
|
|
|
Sounds like you might be compiling for UNICODE.
If so you will need to change all the string types/parameters to their wide-string equivalents.
|
|
|
|
|
it is so excellent , and I hope we can become friends.i'am a mfc beginner,so,i hope that you can help me . thank you 1!
my e-mail is: purefriendsky@live.cn
|
|
|
|
|
Thanks .dan.g. for your code.
I have made a vc++ 2005 version based on your vc++ 6.0 version. thank you.
I modified these:
1. replace char with wchar_t and responding string function.
2. comment
bool CZipper::AddFolderToZip(LPCTSTR szFolderPath, bool bIgnoreFilePath)
{
...
// folders are denoted by a trailing '\\'
// lstrcat(szFolderName, L"\\");
...
}
to avoid empty directory when to zip folder.
3. define ZLIB_WINAPI to avoid error like:
Unzipper.obj : error LNK2001: unresolved external symbol _unzOpenhello to all
|
|
|
|
|
If you send me the relevant zip files, I'll add them to the top of the article.
|
|
|
|
|
Compiling...
Unzipper.cpp
c:\projects\digene\hc2 v4.0\hc2 v4.0 source code\zlib\unzip.h(122) : error C2146: syntax error : missing ';' before identifier 'unzStringFileNameCompare'
c:\projects\digene\hc2 v4.0\hc2 v4.0 source code\zlib\unzip.h(122) : fatal error C1004: unexpected end of file found
This is a Visual C++ 6.0 MFC project, UNICODE.
Any suggestions?
|
|
|
|
|
Hello,
I need to re-build for Windows Vista 64 bit this library.
Do you someone have already approached this job.
Thanks in advantage
a.tess
|
|
|
|
|
Me Too. I Need X64 Version library~
|
|
|
|
|
I have one main folder with subfolders ".moc",".ui",".obj".
These are folders created during compilation one project in linux. Thus my folder structure will look like:
-->MainFolder
xx.pro
Makefile
xx.ui
xx.ui.h
-->.moc
-->a.cpp
-->b.cpp
-->.obj
-->a.o
-->b.o
-->.ui
-->a.ui
The problem is when I zipped this mainfolder to mainfolder.zip with CZipper and extracted the archieve, i got the output as;
-->MainFolder
xx.pro
Makefile
xx.ui
xx.ui.h
There is no .moc,.ui,.obj folders and their corresponding files!!!!!!
But when I zipped it with winzip, no problem with extraction and folders/files are exact match.
Do you have any idea of that?
How can I fix it in CZipper class?
|
|
|
|
|
There is a bug in CZipper::AddFolderToZip. Look at the end of the method:
WIN32_FIND_DATA finfo;
HANDLE hSearch = FindFirstFile(szSearchSpec, &finfo);
if (hSearch != INVALID_HANDLE_VALUE)
{
do
{
if (finfo.cFileName[0] != '.')
{
char szItem[MAX_PATH];
_makepath(szItem, szDrive, szFolder, finfo.cFileName, NULL);
if (finfo.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)
{
AddFolderToZip(szItem, bIgnoreFilePath);
}
else
AddFileToZip(szItem, bIgnoreFilePath);
}
}
while (FindNextFile(hSearch, &finfo));
FindClose(hSearch);
}
As you can see each next file or directory won't be zipped if its name begins with '.'
This is obviously done in order to prevent folders with names '.' and '..' to be zipped.
One of ways to fix this bug and save the correct processing of current and parent folders is change the condition like that:
if (finfo.cFileName[0] != '.')
if (strcmp(&finfo.cFileName[0], ".") && strcmp(&finfo.cFileName[0], ".."))
|
|
|
|
|
I wanted to use the CZipper class with latest zlib (ver 1.2.3). In the process I came across two issues.
ISSUE #1: The constructor does not initialize m_uzFile to NULL. The existing code is as follows:
CZipper::CZipper(LPCTSTR szFilePath, LPCTSTR szRootFolder, bool bAppend) : m_uzFile(0)
{
CloseZip();
if (szFilePath)
OpenZip(szFilePath, szRootFolder, bAppend);
}
bool CZipper::CloseZip()
{
int nRet = m_uzFile ? zipClose(m_uzFile, NULL) : ZIP_OK;
...
}
Since m_uzFile is non-NULL zipClose(m_uzFile, NULL) is called and fails. An exception is thrown.
ONE SOLUTION #1:
Do not call CloseZip() in the constructor and initialize all member variables in the constructor. (I personally like to minimize function calls in constructors.)
ISSUE #2: Appending to an existing zip file overwrites the contents.
In CZipper::OpenZip() the following call is made with bAppend = true:
m_uzFile = zipOpen(szFullPath, bAppend ? 1 : 0).
RESULTS #2:
This deletes the existing zip file's contents and adds a new the file.
EXPECTED RESLUTS #2:
I expect the new file to be APPENDED to the zip file. The existing contents should remain.
SOLUTION #2:
I made the following change that seems to work:
m_uzFile = zipOpen(szFullPath, bAppend ? APPEND_STATUS_ADDINZIP : APPEND_STATUS_CREATE);
zip.h has the following definitions:
#define APPEND_STATUS_CREATE (0)
#define APPEND_STATUS_CREATEAFTER (1)
#define APPEND_STATUS_ADDINZIP (2)
APPEND_STATUS_ADDINZIP is used in zip.c to control the appending code. APPEND_STATUS_CREATEAFTER is never referenced.
Cheers!
|
|
|
|
|