|
See Here[^]. Are you including windows.h or winuser.h in your code?
I am a HUMAN. I have that keyword (??? too much) in my name........
 _AnsHUMAN_b>
|
|
|
|
|
I have included winuser.h
|
|
|
|
|
A watch window will only show the value of a variable if you halt the debugger where the variable is in scope. If it's out of scope (or undefined) the error message will appear.
|
|
|
|
|
You can check the return value of GetLastInputInfo() to see if the function call was successful. You can also use TRACE to show the values inside li on output window.
|
|
|
|
|
Hi all,
I have made a application in which i am reading a port using CreateFile() API with FILE_FLAG_OVERLAPPED parameter as NULL. This all processing i have done in worker thread. Everything is working fine but the problem is when i am trying to close the process i am using CloseHandle API and when the control enters in CloseHandle() the program frezees and there is no option of closing it. The code i am using is as below
void CUse::ThreadStart()
{
ThreadHandle = AfxBeginThread(Thread , (LPVOID) this);
}
UINT Thread(LPVOID pParam)
{
serial_handle = CreateFile(port_arg, GENERIC_READ | GENERIC_WRITE,
0, NULL, OPEN_EXISTING,NULL,NULL);
.
.
.
.
}
void CUse::OnCancel()
{
ThreadHandle->SuspendThread();
if(MessageBox("Are you sure to stop the process?","ReadingPort",MB_YESNO)==6)
{
ZeroMemory(rxBuffer,128);
ZeroMemory(rxtemp,256);
tempid=0;
CloseHandle(serial_handle);
CDialog::OnCancel();
::TerminateThread(ThreadHandle->m_hThread,0);
}
else
ThreadHandle->ResumeThread();
}
How to resolve this problem or any alternate way of doing it...
Thanks in advance
|
|
|
|
|
One thing you can do here is to open the port outside the thread and then pass in the handle to the thread.
I'm saying this because you're opening the port in one thread and closing it in another.
|
|
|
|
|
You've suspended a thread with work still happening on a file handle. Then pulling the rug out from under it. Who know's what was going on in that thread?
Any time I see a thread being suspended from outside, alarm bells ring. TerminateThread just made them louder.
As you're already working with overlapped I/O...
Why not pass your thread a handle to an Event. Then open and close the handle local to the event (this last bit is optional).
Some pseudo code (ie, I don't have access to a compiler right now)
UINT MyThread (LPVOID lpParam)
{
CMyContext *pSomeStruct = (CMyContext *) lpParam;
OVERLAPPED o = {0};
HANDLE hWait = { NULL, NULL };
o.hEvent = hWait [0] = CreateEvent (...);
hWait [1] = pSomeStruct->m_hQuitThreadEvent;
while (1)
{
if (ReadFile (hPort, ..., &o))
{
Dostuffwithdata ()
}
else if (GetLastError () == ERROR_IO_PENDING)
{
nWait = WaitForMultipleObjects (hWait, 2);
if (hWait == WAIT_OBJECT_0)
{
}
else if (hWait == WAIT_OBJECT_0 + 1)
{
CancelIo ();
break;
}
else
{
}
}
}
CloseHandle (o.hEvent);
return nReturn;
}
You have a good amount of work to make the above fit for production, but I hope it sets you on the Right (ie, my example) path.
Iain.
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
|
|
|
|
|
Hi,
Even I face the same problem when i try to close the handle.
I haven't used any thread to create or close the handle.
I have literally used CreateFileW() to create a handle for serial port communication.
hComm = CreateFileW (pcCommPort, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL);
Where pcCommPort is "COM_2"
CreateFileW call succeeds even if device is not connected.
I have send few commands through WriteFile() and read ReadFile() api's and tried to close the handle using
CloseHandle(hComm)
But my application hangs infinitely.
What would be the exact root cause for this issue?
Sample:
While(1)
{
i = 0;
hComm = CreateFileW (pcCommPort, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL);
while(i < 10)
{
i++;
WriteFile(hComm , &txBuffer[0], numBytesToTx, (DWORD*)&numBytesTx, NULL);
ReadFile(hComm , &get_data[i], 1, (DWORD*)&numBytesRx, NULL);
}
CloseHandle(hComm);
hComm = NULL;
}
|
|
|
|
|
Hello Friends
I want to zip some files through c++ coding very fast.I am Already using HZIP way to do but I want to do in some not compressed so it can be done fast.And actually reasong behing doing zip fast is bcoz I wanna zip those file after some regular interval of time in my application so thats y I am looking for some fast way of doing zip.
Thanks In Advance.
Regards
Yogesh
|
|
|
|
|
yogeshs wrote: .I am Already using HZIP way to do but I want to do in some not compressed so it can be done fast
What do you mean by that? Have you looked at open source project like GZip[^]? What do you mean by very fast? Do you have a benchmark with existing ZIP libraries and are you sure that you need a compression program faster than that?
Best wishes,
Navaneeth
|
|
|
|
|
I think he means the "store" method for say winrar so it doesn't compress the files themselves but just puts them into a single archive.
There should be a way to adjust the compression level to 0 and that should speed it up.
|
|
|
|
|
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.
|
|
|
|
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)
