|
well im new to this, and this is getting me little confused. I am not using any data, it is just the mic attached to PC (input device), so which data is bad??
|
|
|
|
|
The line I suspect most is:
WAVEFORMATEX pFormat;
Why would the values be correct (and why do you remove debug statements) while the lot isn't working yet?
I'm not familiar with all this, but from what I see, you either didn't read the documentation or made some mistake. You have two choices: locate the problem yourself, or accurately provide actual code and symptoms.
|
|
|
|
|
There is nothing to hide...following are the lines after the suspected line
pFormat.wFormatTag = WAVE_FORMAT_PCM;
pFormat.nChannels = 1;
pFormat.nSamplesPerSec = 8000;
pFormat.nAvgBytesPerSec = 16000;
pFormat.nBlockAlign = 1;
pFormat.wBitsPerSample = 16;
pFormat.cbSize = 0;
I wanna make it clear that it is logical error (that audio input device is't opening), not the syntax error (if I have made things complicated).
|
|
|
|
|
I don't think your values satisfy the documented requirements:
nBlockAlign (not OK)
Block alignment, in bytes. The block alignment is the minimum atomic unit of data for the wFormatTag format type. If wFormatTag is WAVE_FORMAT_PCM, nBlockAlign should be equal to the product of nChannels and wBitsPerSample divided by 8 (bits per byte).
nAvgBytesPerSec (OK)
Required average data-transfer rate, in bytes per second, for the format tag. If wFormatTag is WAVE_FORMAT_PCM, nAvgBytesPerSec should be equal to the product of nSamplesPerSec and nBlockAlign.
|
|
|
|
|
thanx....thanx alot. I hope I"ll b able to do something better now, while discussing this, I tried all the error options returned by waveInOpen and it was WAVERR_BADFORMAT. lets hope kim clijster wins the US Open once again...
|
|
|
|
|
My app crashed, I did find probrlm point.
to simplify code, I add a line inside crashed function for testing:
BYTE*pp=new BYTE[iSize];
iSize is an int,
if iSize is 1016, the line is OK.
if iSize is 1017, the line crashes, that is, the pointer can't be allocated, or pp is NULL.
My PC has 2G memory, so memory should be OK.
Do you know why?
virus? VC problem? Project settings?
|
|
|
|
|
maybe the statement is executed many times before it crashes your app, as memory is really running low?
you should show actual code to get effective help!
|
|
|
|
|
If that memory is not free'd then you have introduced a memory leak and as stated above me this could very well be the reason for the crash in that its running out of memory, but more code would help greatly.
|
|
|
|
|
includeh10 wrote: My PC has 2G memory, so memory should be OK.
Be aware that each executable file has an header that hold information about the heap commit size and heap reserve size (see /HEAP (Set Heap Size)[^]); the reserve size has the meaning of the maximum stack size that your executable can use, and its default is 1 MB.
If you are allocating more than 1 MB (both in a single shot or with multiple allocations), you can get a similar problem; it doesn't matter if your system is equipped with 2 GB.
|
|
|
|
|
Put the new inside a try/catch block which should give you some more information regarding the crash.
try
{
BYTE*pp=new BYTE[iSize];
}
catch (exception& e)
{
cout << e.what();
}
|
|
|
|
|
«_Superman_» wrote: try
{ BYTE*pp=new BYTE[iSize];}catch (exception& e){ cout << e.what();}
It one the correct way to resolve problem, but still there are some exception which can't be handlled by exception block too.
"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
|
|
|
|
|
Seeing as the man said the pointer was sometimes 0 when it came back from new he's using an antique compiler which doesn't follow the standard (e.g. VC++6). Catching anything isn't going to help here.
Cheers,
Ash
|
|
|
|
|
It could be a symptom of another memory problem elsewhere. Enable memory testing and rerun your program.
It could also be (as someone else suggested) a memory leak being repeatedly executed. If so, this one is easy to fix: make the bb variable static and initially NULL. Then if it's not NULL, free it before assigning the new buffer to it.
|
|
|
|
|
In visual Studio, there is a shortcut for going to the function definition. Let me give an example
VOID ABC::abc() {
int result;
result = someFUNC();
}
Now if we press some shortcut key on someFUNC, it takes us to that function. What is that shorcut?? thanx
|
|
|
|
|
Place your mouse over the function and press Right-Click, the pop-up menu will show you the option. In VC++ Express Edition it is F12.
It's time for a new signature.
|
|
|
|
|
F12 will work not only on Express editions
|
|
|
|
|
By my knowledge, in order to make a class recognizable in another module of an application, I need to include it's header file or, at least, to use a forward declaration.
I'll ask my question using an example. Let's suppose I have an application named Test. In the CTestView class I have the function GetDocument() returning a pointer of CTestDoc* type. How doess the view class know about the CTestDoc* type if there is no "#include TestDoc.h" declaration in the CViewTest class ?
|
|
|
|
|
As you have mentioned, to use CTestDoc*, you will have to include TestDoc.h. If the CTestDoc* referenced only in the .CPP file, then check if the .CPP has included TestDoc.h
|
|
|
|
|
The obvious thing to do is look at what headers are included in CTestView.cpp and see if one of those contains a #include CTestDoc.h.
It's time for a new signature.
|
|
|
|
|
Somewhere there's a declaration for CTestDoc. Quite where it is might be another matter. You might find it's somewhere obscure i.e. in CTestView you include the document header before the view header but it'll be there.
Cheers,
Ash
|
|
|
|
|
I'm assuming you're asking how CTestDoc is referenced in the CTestView class in the TestView.h file.
If you look in the TestView.cpp file you will see the following 2 lines -
#include "TestDoc.h"
#include "TestView.h"
Here you will notice that TestDoc.h is included before TestView.h.
This way the CTestView class already knows about the CTestDoc class.
Change this to the following and you can expect errors at exactly the place where you're talking about -
#include "TestView.h"
#include "TestDoc.h"
|
|
|
|
|
Thanks for the help, I learned something from everybody who answered.
_Superman_'s answer was the shoot right in the bull's eye.
|
|
|
|
|
CString(0xcccccccc) wrote: How doess the view class know about the CTestDoc* type if there is no "#include TestDoc.h" declaration in the CViewTest class ?
Probably the include is done by one of the standard MFC include (afx.h or something similar)
In general, the document does not know the view(s); the view know about the document (GetDocument)
When the document (CDocument derived class that contains the data(*)) is modified then there should be a message is sent to update the views or in the case of the CDocument a method is called (CDocument::UpdateAllViews) that will eventually call (by message?, don't recall the exact mechanism) CView::OnDraw which should be overriden in your CView derived class so that the view is refresh after a change in the CDocument..
Watched code never compiles.
|
|
|
|
|
hello guys....well sometimes it happens that when I modify my code, despite savinf the changes in the code, following error occurs
fatal error LNK1000: Internal error during IncrBuildImage
wat can be the reason??
|
|
|
|
|
Microsoft has a patch for this. Search their site for this error message.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
