|
hello Guys
Thanks For ur Reply.Now,currently I am using that open source of that zip.zpp and .h file.And I didnt use gzip.I will look into that but In actual I want that elchupathingy says,I want just winrar as store not compression.
Thanks & Regards
Yogesh
|
|
|
|
|
Hello guys
Is any other way to Zip folder with faster way.Is there any other API than GZIP.DO anyone having Idea of using Boost Library?
Thanks & Regards
Yogesh
|
|
|
|
|
Hi Yogesh, I had a quick look at the zlib library and there I found in zlib.h (line 183):
#define Z_NO_COMPRESSION 0
#define Z_BEST_SPEED 1
#define Z_BEST_COMPRESSION 9
Perhaps use a class generating ZIP-files (with zlib as compression library) with the argument Z_NO_COMPRESSION? *untested*
/M 
|
|
|
|
|
Below is my code.It work well in VC6, but when i convert it into VS2008, the compile complain that
Error 12 error C2678: binary '==' : no operator found which takes a left-hand operand of type 'std::_Vector_iterator<_Ty,_Alloc>' (or there is no acceptable conversion)
vector<CTestEntry>::iterator iter;
for (iter = m_listTest.begin(); iter != m_listTest.end(); iter++)
{
if (iter) <big><==Error in VS2008, i had try with if(iter ! = NULL) but still in error.</big>
{
DoSomething();
}
}
Any ideal to solve these problem?
|
|
|
|
|
You shall not test iterators for NULL. They should only be tested for (in-)equality with the end of the container supplying them. (or other iterators from the same container)
Edit: Is this what you are trying?
if(*iter != NULL)
home
modified on Monday, August 9, 2010 1:59 AM
|
|
|
|
|
DevelopmentNoob wrote: Any ideal to solve these problem?
vector::iterator<ctestentry> iter;
for (iter = m_listTest.begin(); iter != m_listTest.end(); ++iter)
{
DoSomething();
}
The iterator of an STL container must not be tested against NULL, so the code above works just fine. Or did you want to test an element in the container?
|
|
|
|
|
You are paying the price for using an implementation detail of the Microsoft's standard library implementation. The idea that your code "work well" is only true if you like writing redundant stuff.
In Microsoft VC++ 6 (also known as VC++'98 to give you an idea of how much of an antique it is) std::vector::end returned NULL, so the check for if(iter) is completely redundant - you can remove it on VC++6 and not see any observable difference.
So the rules are...
- Don't assume anything about the implementation of an iterator
- Don't compare iterators against anything that isn't another iterator of the same type - that includes NULL, 0, nullptr, nullptr_t()
Cheers,
Ash
|
|
|
|
|
hello guys...im havinf a problum with waveOutOpen. When I call this function, it returns no message, upon debugging the MMRESULT variable was showing a value of 11...here is the code
WAVEFORMATEX _oFormat;
LPWAVEFORMATEX _pFormat = NULL;
PCHAR _pWaveData[4];
LPWAVEHDR _pWaveHeader[4];
LPHWAVEOUT _hOutputDevice = NULL;
DWORD _nAlignedBufferSize = 0;
MMRESULT rc = 0;
_pFormat = &_oFormat;
_pFormat->wFormatTag = WAVE_FORMAT_PCM;
_pFormat->nChannels = 1;
_pFormat->nSamplesPerSec = 8000;
_pFormat->wBitsPerSample = 8;
_pFormat->nBlockAlign = 1;
_pFormat->nAvgBytesPerSec = 8000;
_pFormat->cbSize = 0;
rc = waveOutOpen(_hOutputDevice, WAVE_MAPPER, _pFormat, (DWORD) &waveOutProc, 0, CALLBACK_FUNCTION);
if (rc==MMSYSERR_NOERROR)
MessageBox(NULL,"device opened..","",NULL);
else if (rc==MMSYSERR_ALLOCATED)
MessageBox(NULL,"device already allocated","",NULL);
else if(rc==MMSYSERR_BADDEVICEID)
MessageBox(NULL,"bad device id","",NULL);
else if(rc==MMSYSERR_NOMEM)
MessageBox(NULL,"no memory","",NULL);
else if(rc==MMSYSERR_NODRIVER)
MessageBox(NULL,"no driver","",NULL);
else if (rc==WAVERR_BADFORMAT)
MessageBox(NULL,"bad format","",NULL);
else if(rc==WAVERR_SYNC)
MessageBox(NULL,"not syncrnoized","",NULL);
what can be the problum?? 
|
|
|
|
|
A quick look in the header file reveals that error code 11 is MMSYSERR_INVALPARAM, which suggests one of your parameters is wrong. Looking at your code you should be passing addresses of variables for parameters 1 and 3. Your declarations using the 'LP' prefix is not sufficient to do this. A quick review of variables and pointers to variables is in order I think.
It's time for a new signature.
|
|
|
|
|
thanx...I removed LP from LPHWAVEOUT and passed the address for variable 1. But question remains that why LP is not enough??
|
|
|
|
|
A lot of Windows API functions take or provide data through some structure, so you need to provide the structure (i.e. allocate memory for it), fill it (if it is input data), and pass a pointer to it. Passing a pointer "to nowhere" isn't going to cut it.
|
|
|
|
|
A statement of the form:
LPHWAVEOUT _hOutputDevice = NULL;
states that _hOutputDevice is a pointer to a HWAVEOUT (whatever that may be). However, you have also initialised it to the value NULL which means that it is not pointing to anything. If you then pass that as the function parameter then the function will reject it as part of the response is to return some data in the memory that is pointed to. Since the value is NULL the function cannot store the response.
It is much better practice to do something like:
HWAVEOUT _hOutputDevice;
function(&_hOutputDevice, ...
It's time for a new signature.
|
|
|
|
|
Hi,
Over the years I have written a number of MFC extension DLLs which, amongst other things, contain resources (mainly dialogs) which can be accessed from the main app as well as from code within the DLL itself.
Occasionally I ran into problems of the resource ID's clashing with those of the main app, and to avoid this, I have always tried to allocate resource IDs in different ranges in each DLL. This has worked OK but it is getting increasingly difficult to manage and I thought that there must be a more elegant way to ensure that you can access the correct resource.
Any suggestions? 
|
|
|
|
|
I've been using AfxSetResourceHandle() for that. Call once before accessing a resource, and use it afterwards to reset the handle. Of course you will have to know what dll contains your resource. Depending on your architecture, this can be really simple, or close to impossible  On way to solve some of these problems is to have factory functions exported from the dll for creating dialogs and such.
Inside each dll this is not a problem if you are using the AFXMANAGESTATE (?) macro which I assume you are doing, and you are not accessing resources in other dll's.
|
|
|
|
|
Hi Niklas,
Thanks for the reply. I do need to invoke the dialogs contained in my DLL from the main application but your suggestion of using a factory function is a great idea and should do the trick.
Thanks for your help 
Tony
|
|
|
|
|
Hi all,
in my program this error C1061 compiler limit : blocks nested too deeply comes,i m using number of if else,please tell me how can i resolve this,
thanks in advance.
|
|
|
|
|
Without seeing your code it is hard to tell, genericly you can either try to re-structure the whole thing, or divide it into multiple functions, or, if everything else fails, -oh my i hope no lightning will strike me now *ducks and covers*- use goto, but as said, without seeing actual code, it is hard to say...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
I have a TreeCtrl,with number of Tree items.
get currently selected tree item and perform function on it respectively.
CString Tree_str;
BOOL flag;
if(Tree_str==_T("Item 1"))
{
if(flag==TRUE)
{
}
else if(flag==FALSE)
{
}
}
else if(Tree_str==_T("Item 2"))
{
if(flag==TRUE)
{
}
else if(flag==FALSE)
{
}
}
.
.
.
.
else if(Tree_str==_T("Item 140"))
{
if(flag==TRUE)
{
}
else if(flag==FALSE)
{
}
}
|
|
|
|
|
This is nowhere near deep enough to generate that message, I suspect something else is wrong with your source.
[edit]Something for the weekend? ... MuraliKrishnaP spotted the obvious point that I missed, which is that you have exceeded the 128 nest limit because of the number of if .. else if statements.[/edit]
It's time for a new signature.
modified on Saturday, August 7, 2010 9:32 AM
|
|
|
|
|
The following code
if(a)
{
}
else if (b)
{
}
else if(c)
{
}
is nothing but
if(a)
{
}
else
{
if (b)
{
}
else
{
if(c)
{
}
}
}
else, you can also do like this. Will this solve your problem?
if(a)
{
if(flag)
{
}
else
{
}
}
if(b)
{
}
if(c)
{
}
|
|
|
|
|
You can turn that into a regular switch, here is the scenario in pseudo-code:
int n=extract the number from string Tree_str;
switch (n) {
case 1:
...
break;
case 2:
...
break;
...
}
it will result in less code and faster execution!
|
|
|
|
|
Shave the levels down to 123 or less.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
|
fail
{
DWORD dwBytes;
int res = WSAIoctl(s,
SIO_GET_EXTENSION_FUNCTION_POINTER,
&GuidConnectEx,
sizeof(GuidConnectEx),
&g_lpfnConnectEx,
sizeof(g_lpfnConnectEx),
&dwBytes,
NULL,
NULL);
int err = WSAGetLastError();
assert(res==0);
}
DWORD bytes_sent;
BOOL ok = (*g_lpfnConnectEx)(s, (sockaddr*)&addr_in, sizeof(addr_in), NULL, 0, &bytes_sent, NULL);
int err = WSAGetLastError();
assert(ok);
succeed
int ok = connect(s, (sockaddr*)&addr_in, sizeof(addr_in));
assert(ok==0);
why?
|
|
|
|
|
The documentation says that when you call ConnectEx, the socket must be already bound.
The connect function binds the socket for you. That must be why connect succeeds when ConnectEx fails.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Java | [Coffee]](https://codeproject.freetls.fastly.net/script/Forums/Images/coffee.gif)
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
