|
Yes, m_strTable is a CString variable.
Then what's wrong with the query.
Is might be becoz of improper connection
|
|
|
|
|
The CString does not only contain a pointer to a character array, but also more information such as allocation size and length of current data. If you use a CString as an argument you will push all that to the stack, when in fact you only want the pointer to the character array on the stack, as described by the format specifiers to CString::Format(). You will simply mess up the arguments/stack. Do the conversion I suggested in the answer above to avoid this.
This is one reason to avoid variable arguments whenever possible. The compiler cannot perform type checks.
Does your code still fail?
|
|
|
|
|
Hi all,
this error comes when i am using win32 dll in c# application.
An unhandled exception of type 'System.BadImageFormatException' occurred in Test.exe
Additional information: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
please help me for this.
thanks in advance.
|
|
|
|
|
Please ask in the C# forum.
|
|
|
|
|
Are you building both the binaries on the same platform? 32 bit or 64 bit ?
|
|
|
|
|
|
Try this one, make your application run inside WoW64. For that go to the project properties, select the "build" tab and set the "platform target" to x86.
FYI : Read this.[^]
|
|
|
|
|
thanks,its working fine
but its safe and secure for further use.
is C# application work for all platform x86 and x64.
|
|
|
|
|
It depends for which platform you are building.
|
|
|
|
|
Hi all,
I am using visual studio 2010 and sometimes when i try to create a variable using add member variable wizard, it is not created. Try again and again and it is not created make a new dialog box and a new control then it is created.
can anybody please help me with this.
|
|
|
|
|
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++
|
|
|
|
|
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++
|
|
|
|