|
You should be posting this in the microsoft connect website as a bug.
On a different note, you could manually do what the wizard does and add a member variable by adding code.
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
I've noticed the same thing. It usually works again the next time you have reopened the project/solution. If you really need this wizard to work, try reloading your project.
If you know what to add, you can do it more quickly manually than using the wizard anyway.
|
|
|
|
|
The wizards are generally unreliable, they're buggy, specially if you mess with any of the code they've generated (and the text comments/tags it inserts for itself). My recommendation, learn to do everything without wizards. It'll make you an overall better developer and will keep you from relying on something that works part of the time.
|
|
|
|
|
I have tried adding those variable manually but when i try to use those variable it gives error undeclared identifiers.
|
|
|
|
|
Means you're probably forgetting to do something. I do this by hand all the time, and unlike the wizards, it works every time. Like I said, nothing wrong with using the wizards, but they're not the most reliable thing ever implemented.
|
|
|
|
|
Hi,
In my application for one child window,im having more than 100 pages.When page up and page down im moving coresponding next pages.BEfore getting next page, im destroying the previous page by using DestroyWindow.
But when i see in the Task Manager,Perormance Tab,The PF usage shows for every page it increasing 0.01GB and in Physical Memory(K)-Available the number(ex:1571826)is getting reduced and soon one error is coming like
"Out of memory,edit".
Im pasting here my PageUp and Pagedown code:
void CGraphView::OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags)
{
if(nChar == 33 || nChar == 34)
{
short iTempPgNo = ((CMainFrame*)AfxGetMainWnd())->m_ngiSchPNo;
if(nChar == 33)
{
iTempPgNo--;
}
else
{
iTempPgNo++;
}
if(iTempPgNo != m_ngiSchPNo)
{
CString sNo;
if( gpGView[nCurrGrpView]->glg_animation[giSchPNo].m_hWnd )
{
gpGView[nCurrGrpView]->glg_animation[giSchPNo].DestroyWindow();
giSchPNo = iTempPgNo;
if(giSchPNo > giGraphicCnt)
giSchPNo = giGraphicCnt;
((CMainFrame*)AfxGetMainWnd())->m_ngiSchPNo = giSchPNo;
}
}
}
CView::OnKeyDown(nChar, nRepCnt, nFlags);
}
Eventhough im using DestroyWindow(),why the memory is getting increased for each page down.
Anu
|
|
|
|
|
Only frame windows destroy their associated C++ object when DestroyWindow is called. With CWnd-derived windows only the Windows UI HWND is destroyed when DestroyWindow is called. Do you need to delete a CWnd object too or are you reusing them? Or are they frame windows?
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
|
CGraphView is one of the childframe, this class is using to show Graphics window.We are using one third party DLL to show the gaphcis page(glg_animation).
Anu
|
|
|
|
|
glg_animation[giSchPNo].DestroyWindow()
after destroying this window, are you still using glg_animation[giSchPNo] object ? What if user visits this page again? Do you create glg_animation[giSchPNo] window?
And it would be better if you post your paint event function too.
Apart from this, I noticed that you are using an array to hold the number of pages and destroying each window after page is scrolled. This shows that you'll be holding one page in the memory, then why are you using an array? Instead, you can create the page objects dynamically.
|
|
|
|
|
if( !glg_animation[giSchPNo].m_hWnd )
{
char pFileName[500];
memset(pFileName,0,500);
strcpy(pFileName,FName[giSchPNo]);
glg_animation[m_ngiSchPNo].Create( pFileName,this);
..
...
}
In OnDraw() im doing like this.Initailly i store all 100 pages name in FName array.
Im destroying this varaibles in OnDestroy() using delete operator when im closing the window.
Anu
|
|
|
|
|
But calling the DistroyWindow isn't enough.
Check whether the create() function is successful, or you may end up in creating the window every time you enter paint event which will run your app out to memory soon.
Try using the single glg_animation instead of an array, as you're creating / deleting the pages dynamically. This will reduce your memory usage, as at a time only one object will be in use from an array.
|
|
|
|
|
"The waveInAddBuffer function sends an input buffer to the given waveform-audio input device. When the buffer is filled, the application is notified."
Please translate this geek talk to English for me please.
I am having an issue understanding what exactly is going on in waweInxxx API.
I understand the need to do waveInPrepareHeader which INHO prepares the buffer and not the header. Now I need to do waveInAddBuffer to "connect" the device to this buffer / header.
After waveInStart and as soon as this buffer is filled "the application is notified."
In my case via callback function which gets WIM_DATA.
Now I can process the buffer / header. I am saving the data into file.
Two questions - since the device is still opened it could fill up THE SAME BUFFER again if I keep it "connected" via waveInAddBuffer.
So, can I just cleanup the buffer and be done or do I need to "reconnect" it?
The second question - how many of these buffers are needed assuming they can be reused as I described?
I would guess I could miss some data while processing the current content of the buffer if I do this.
So, how do I keep track of multiple buffers?
Any constructive help will be as always appreciated.
Cheers
Vaclav
|
|
|
|
|
I wouldn't use any less than two buffers. How many you use would depend on how much processing time there is for each buffer and how long the buffers are (time-wise).
You don't need to unprepare and prepare the buffers each time you receive a filled buffer. Prepare them all and add them with waveInAddBuffer before starting capture. Unprepare them all after stopping. As you receive each filled buffer you can just re-queue it with waveInAddBuffer.
To keep track of all the buffers? Put them in an array or some other collection 
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Thanks Mark.
I think I am beginning to see the light.
What I met by keeping track of the buffers - the callback function executes when the current buffer is filled with data.
Now I do this:
if(WHDR_DONE==(WHDR_DONE & pHeader->dwFlags))
{
// writes a specified number of bytes to a file
lBytesWritten = mmioWrite(m_hOPFile,pHeader->lpData,pHeader->dwBytesRecorded);
mRes = waveInAddBuffer(m_hWaveIn,pHeader,sizeof(WAVEHDR));
}
That puts the current buffer back to what - buffer queue? I prepared 3 buffers.
So how does the OS knows about this queue?
Do I have to do waveInReset before I put it back?
What will happen if I screw up and run out of buffers?
One more - I cannot find anywhere how did the paramater1 became the WAVEHDR pointer.
There must be some "common" standard for the first parameter because I see similar stuff in creating worker thread.
BTW is there any trick you know how to verify that the buffer data is valid?
I am obviously getting "buffer full" by executing the callback, but get 0 in dwBytesRecorded. I am guessing my format setup is wrong.
|
|
|
|
|
Vaclav_Sal wrote: how does the OS knows about this queue?
The system keeps track of the buffers once you hand them over using waveInAddBuffer()
Vaclav_Sal wrote: Do I have to do waveInReset before I put it back?
You don't have to do anything, especially don't call waveInReset() which stops recording and releases all the buffers.
Vaclav_Sal wrote: What will happen if I screw up and run out of buffers?
Gaps in the audio maybe? I'm not sure - you may have to look that up, or try recording with one buffer and see what happens
Vaclav_Sal wrote: I cannot find anywhere how did the paramater1 became the WAVEHDR pointer.
Documented![^]. Yes it may be a common API design in Win32, but isn't related to anything else.
Vaclav_Sal wrote: I am obviously getting "buffer full" by executing the callback
YOU shouldn't be executing the callback. Callbacks are called by the system, which is why they are called callbacks If you are calling it then that's wrong!
In your callback function, check the message. If it's WIM_DATA then check the flags in the WAVEHDR struct. If the WHDR_DONE flag is set then waveInReset was called so don't add the buffer back in. Else look at the dwBytesRecorded value for how many bytes are there. I suppose if it's 0 just put it back in with waveInAdd.
If the format is wrong then you should know that when you call waveInOpen() - long before you set up buffers.
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark, I need to rephrase my comments.
I am questioning the process after the callback function is being executed as a result of the buffer / header being full.
In one of the codes I have been learning from I found the following snippet
case WIM_DATA:
{
TRACE("%d",pHdr->dwUser);
if(WHDR_DONE==(WHDR_DONE &pHdr->dwFlags))
{
mmioWrite(m_hOPFile,pHdr->lpData,pHdr->dwBytesRecorded);
mRes=waveInAddBuffer(m_hWaveIn,pHdr,sizeof(WAVEHDR));
if(mRes!=0)
StoreError(mRes,TRUE,"File: %s ,Line Number:%d",__FILE__,__LINE__);
}
…
I feel since the callback receives WIM_DATA message cheking for header WHDR_DONE is redundant.
However, I do question how dwByteRecored can be 0 if the buffer was being full.
Obviously it is not full.
So how did the callback got to be executed with no data recorded?
Vaclav
.
|
|
|
|
|
Vaclav_Sal wrote: if(WHDR_DONE==(WHDR_DONE &pHdr->dwFlags))
That looks wrong to me unless there's only one buffer and the entire recording is done in that one buffer. But then it doesn't make sense because it calls waveInAddBuffer()...
I think it should be
if(WHDR_DONE != (WHDR_DONE &pHdr->dwFlags))
Vaclav_Sal wrote: I feel since the callback receives WIM_DATA message cheking for header WHDR_DONE is redundant.
If you look at the WIM_DATA documentation it states "The message can be sent when the buffer is full or after the waveInReset function is called. ". So when waveInReset is called the buffer will probably be empty and the WHDR_DONE flag will be set. That's what your check above is failing on....try switching it to !=
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Thanks for your help Mark
I finally managed to start, record and stop an audio file.
When I step thru the process first two "buffers" have no data recorded.
As you suggested , I just return the empty buffer back into the queue.
As far as I can tell there is nothing missing in the file and no waveInReset was performed.
But is is really noisy – background noise. I'll play with it to see how to improve the noise.
Vaclav
|
|
|
|
|
I have a varibale of 8 bytes (ULONGLONG). How to extract first 6 bytes from that?
|
|
|
|
|
Bit Masking[^]
"Real men drive manual transmission" - Rajesh.
modified on Tuesday, July 5, 2011 9:43 AM
|
|
|
|
|
Bitwise?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Brain fart. 
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
{OT} where is your MVP tag??
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
The MVP tag? That, I lost in the forest.
Actually, I didn't win it this year.
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
#include <windows.h>
#include <iostream>
using namespace std;
union MyUnion
{
ULONGLONG ull;
BYTE b[8];
};
int main()
{
ULONGLONG v = 0x0123456789ABCDEF;
MyUnion mu;
mu.ull = v;
for (int i=0; i<6; i++)
{
cout << hex << (INT) mu.b[i] << endl;
}
}
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
