|
Well now.. I got the following problem. My app does not leak memory, however, the available physical memory (returned by call to GlobalMemoryStatus() )seems to decrease during the lifespan of the application. This is due to memory fragments that are lost(??) caused by the many memory allocations-deallocations in the program.
What my question is now. If I would run the app for a looooong time could that result in a crash of the system?? I mean does the system really lose the unallocated memory fragments inbetween some allocated memory fragments resulting in a possible out-of-memory error while there actually is still a lot of memory available?
If I would have for example unallocated memory of 1kb between two blocks of allocated memory and I want to allocate 1kb will it use that unallocated part or will it allocate the memory behind the last still allocated mem chunk...
If anybody can help me with that...
Greetings,
Davy
|
|
|
|
|
Hello,
I am using eVC 4.0 with ARM processor.
The problem is
_bstr_t bstrProvider(TEXT("Microsoft.SQLSERVER.OLEDB.CE.2.0")); throws a Datatype Misalignment exception, even though I'm able to execute the same code on the Pocket PC 2003 emulator.
Any insights ?
Thanks and regards,
Amit
|
|
|
|
|
One clarification in this context is required. I am trying to use PXA255 based pocket PC with the SQL Server CE 2.0.
There is only one set of installation files for ARM processors under Sa1100.
The question is, can it a possibilty that the DLLs meant to be used on SA1100 platform don't have data compatibility with PXA255 ? That would explain why it is working in emulator and not with the device.
I have also tested with PXA250 based device and the application runs perfectly fine.
Any advice would be of great help.
Thanks and regards,
Amit
|
|
|
|
|
Can the ADOCE and OLE DB Files for ppc 2002 be used for ppc 2003 ?
Everywhere in the installation instructions for SQL Server CE 2.0 it is mentioned to use Microsoft eMbedded Visual Tools 3.0 while I am using eVC 4.0. If I cannot use the same files, where to look for the files to be used with ppc 2003 ?
|
|
|
|
|
nigs_krec wrote:
Can the ADOCE and OLE DB Files for ppc 2002 be used for ppc 2003 ?
Yes. I have done it and it works.
Regards,
João Paulo
|
|
|
|
|
Hello,
I am using eVC 4.0 and Pocket PC 2003 emulator. I am trying to install SQL Server 2.0 on the emulator as per the online books provided with the installation. The problem is when I try to copy ADOCE and OLE DB Files onto the emulator, it pops up a dialog to confirm overwriting few system files (adocedb30.dll for example). When I select Yes, it says access denied, make sure disk is not write protected and the file is not in use. The only application running on the emulator at this time is file explorer.
Any help is appreciated.
Regards,
Amit
|
|
|
|
|
Skip any files the emulator does not allow you to overwrite.
Regards,
João Paulo
|
|
|
|
|
hi,
Does anybody know if it is possible to launch a notification with a application and get back the data with another one, running in background. I found very few things about SHNotificationGetData() but I'm not sure of the meaning ... I work with VC++3.0
thx !
|
|
|
|
|
I would like to mention this to you fellow programmers who program for Pocket PC`s.
My last project concerned an application that I wrote for a device on MIPS platform and ARM, I developed using emBedded C++ 3.0 for the MIPS, and embeddedC++4.0 for the ARM. It was a dialog based application and almost all dialogs were created dynamicaly when needed. What happened now is that there seemed to be a big memory leak.
Checking the code revealed nothing. Everywhere dynamically created objects and arrays were correctly deleted. The few brushes that were created with CreateSolidBrush were all deleted with DeleteObject at the correct time. It was very bizarre.
However, I did find a way to get rid of the memory leak! That^s what I want to inform you about.
What I did was everywhere where I called DeleteObject on the CBrush objects I replaced the call with
HGDIOBJ HObj = m_Brush.Detach(); //m_Brush is CBrush object previously created with
//m_Brush.CreateSolidBrush(ACOLOR);
if(HObj)
::DeleteObject(HObj);
This replacement got rid of the memory leak. I do not know why the DeleteObject of the CGDIObject class did not do it, maybe it is Project setting I overlooked, but if that is the case, damn, pretty bizarre to need a proj setting for the delete member func while the create works just fine.
If it is a 'bug' in MFC on these platforms I hope that with this post some future programmers are saved from some serious annoying almost untraceable mem-leak search!
(I assume the same will happen for CPen, and other from CGDIObject derived classes. so this little replacement might save you some mem-leaks)
Greetings to you all,
Davy
|
|
|
|
|
Interestingly, MFC should be doing that. If you look at the source code (wingdi.cpp, 1208), you see (hope I'm not breaking Microsoft's copyright):
BOOL CGdiObject::DeleteObject()
{
if (m_hObject == NULL)
return FALSE;
return ::DeleteObject(Detach());
}
This code does essentially what yours does because m_hObject is the handle to the GDI object that gets returned by Detach() . So this brings me to a question: How were you deleting your CBrush objects?
m_Brush.DeleteObject();
DeleteObject(m_Brush);
Regards,
João Paulo
|
|
|
|
|
I was executing your option 1.
m_Brush.DeleteObject();
Believe me it suprised me too!
But I noticed the mem leak was caused by my brushes that were not getting deleted.
So that`s when I just figured let`s really make sure it is actually getting deleted...
and I replaced all the m_Brush.DeleteObject() with the codefragment I mentioned above. I did not add this in places where I did not call m_Brush.DeleteObject before, And it was the only change I made. So I am sure that that was the reason for my memory leak..
I know that the CGdiObject class should basically do that when calling it through the CBrush object, but why it didn^t happen here??? beats me.
Greetings,
Davy
|
|
|
|
|
|
Hello,
The program I wrote seems to have a memory leak or leaks, however I can`^t seem to trace it.
I allready overrode the new and delete operator to check if somewhere I might have forgotten a delete, (which I had, shame on me!) but still I seem to leak memory.
I call the GlobalMemoryStatus from time to time and check the available physical memory on the device. Unfortunatly that amount seems to decrease as the program runs.
I figured perhaps the memory is lost somewhere in calls like CreateBitmapIndirect and forgot a DeleteObject (although I checked that one and I think I Delete all of èm), in short I am desperate and if anybody knows a way to trace memory leaks (other then caused by new and delete) in windows ce.net please let me know...
Greetings,
Davy
|
|
|
|
|
Try using a professional tool for that. I would advise using Entrek[^]'s tool. They have a 14 day trial version. (I don't work for them.)
The fact that available memory decreases is not by itself an indicator of a memory leak. The pattern in which memory is allocated and deallocated is very important for this matter. For instance, if you are reallocating buffers in order to increase their sizes, the expected outcome is that the freed memory will not be reported back to you (it got stuck in the middle of other allocation blocks).
Regards,
João Paulo
|
|
|
|
|
Thanks for the reply!
Downloaded the trial version Is a nice tool . Found the cause of my mem leak. Undeleted brushes that were created with CreateSolidBrush! Although in the code they are all deleted.
|
|
|
|
|
Please HELP!!!
I've got some problem and i'll try to describe it as clearly as I know english
In my programm i use Timer and by defined period of time i pait some figure or text on my
Device Context. Everything is going ok for a while. But if i'll wait for example more than 5-6 minutes
i "lose my device context" i think. When i try to push one of the menu items, the menu doesnt apears.
And when i close my programm Windows CE can't repaint some areas.
Is it a Windows Bug???
How to avoid this???
|
|
|
|
|
Looks like you have a resource leak on your paint code. Can you show it?
Regards,
João Paulo
|
|
|
|
|
The code Looks like this:
The timer function:
CChildView::OnTimer(UINT nTimer)
{
CDC* pDC = GetDC();
pDC->Something;
}
That is all.
Thanks for participating.
|
|
|
|
|
You must release the DC. Change the code like this:
CChildView::OnTimer(UINT nTimer)
{
CDC* pDC = GetDC();
pDC->Something;
pDC->ReleaseDC();
}
Regards,
João Paulo
|
|
|
|
|
Hi everyone,
Can anyone please tell me how to use File open dialog box using eVC 3.0 ? COMDLG32.LIB is not supported in eVC thats why this question.
Thanks in advance.
Regards,
Amit
|
|
|
|
|
Check the GetOpenFileName and GetSaveFileName functions.
Regards,
João Paulo
|
|
|
|
|
Hi João,
GetOpenFileName() results in the required dialog but when a selection is made and OK pressed, the application hangs. However, if a Cancel is pressed, the control goes back to the window. I have done the proper initialization of OPENFILENAME structure as follows. Can you give me some more ideas about the possible causes ?
Thanks in advance.
Regards,
Amit
lpofn.lStructSize = sizeof(OPENFILENAME);<br />
lpofn.hwndOwner = hWnd;<br />
lpofn.lpstrFilter = OLESTR("DD Files(*.fms)\0*.fms\0All Files(*.*)\0*.*\0\0");<br />
lpofn.nFilterIndex = 0;<br />
lpofn.lpstrFile = pcstrFileName;<br />
lpofn.nMaxFile = sizeof(pcstrFileName);<br />
lpofn.lpstrFileTitle = NULL;<br />
lpofn.lpstrInitialDir = NULL;<br />
lpofn.lpstrTitle = OLESTR("Select DD file !");<br />
lpofn.Flags &= (OFN_FILEMUSTEXIST);<br />
lpofn.nFileOffset = 0;<br />
lpofn.nFileExtension = 0;<br />
lpofn.lpstrDefExt = NULL;
|
|
|
|
|
nigs_krec wrote:
lpofn.Flags &= (OFN_FILEMUSTEXIST);
Has this member been initialized before? Did you clear the record before using it?
Regards,
João Paulo
|
|
|
|
|
Hi João,
Yeah the member has been already initialized before its usage.
Do you think there is any other possibility ?
Also, could you please suggest some alternative to GetOpenFileName(). I think the problem lies only in GetOpenFileName() because the application hangs just by executing that statement even if all the other code is commented out. That essentially narrows it down to the improper initialization of OPENFILENAME structure.
Many thanks.
Regards,
Amit
|
|
|
|
|