|
I want to create a DLL which will be used in an EXE. In the DLL, I want to export some simple classes, but they use MFC's CString as memebers. What kind of DLL should I create, how to export them, and import them. Should I use AFX_EXT_CLASS instead ? However, I'm planning remove MFC dependency by using some kind of CString clone in the future.
I tried use __declspec(dllexport) and __declspec(dllimport) with created the DLL as regular MFC DLL. However, in using it, in deleting the heap allocated instances, it has memory violation.
Can anyone tell me the hints ?
|
|
|
|
|
Use the multithreaded DLL version of the C run-time library in both the DLL and the EXE. This will ensure only one heap is used globally.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I checked both the EXE and the DLL are using Debug Multithreaded DLL.
|
|
|
|
|
You must create a MFC Extension Dll and declare your classes with the AFX_EXT_CLASSES like this:
class AFX_EXT_CLASS CMyClass
{
....
};
Best regards,
Alexandru Savescu
|
|
|
|
|
hi,
how do i know when users dial-up to the internet (if success), and when they disconnect from internet ????
thanks !
lenhan
|
|
|
|
|
Check internet part in CP,you have to use sockrt programming codes:
http://www.codeproject.com/internet/
Mazy
"The path you tread is narrow and the drop is shear and very high,
The ravens all are watching from a vantage point near by,
Apprehension creeping like a choo-train uo your spine,
Will the tightrope reach the end;will the final cuplet rhyme?"Cymbaline-Pink Floyd
|
|
|
|
|
Linking...
mfcs70d.lib(stdafx.obj) : fatal error LNK1000: Internal error during Pass2
Version 7.00.9466
ExceptionCode = C0000005
ExceptionFlags = 00000000
ExceptionAddress = 1031C9BE (10300000) "C:\Program Files\Microsoft Visual Studio .NET\Common7\ide\mspdb70.dll"
NumberParameters = 00000002
ExceptionInformation[ 0] = 00000000
ExceptionInformation[ 1] = 42306940
CONTEXT:
Eax = 10002F4A Esp = 0012E940
Ebx = 10003F4A Ebp = 0012EA7C
Ecx = 023EFEF0 Esi = 02257090
Edx = 022FAC18 Edi = 023EFEEC
Eip = 1031C9BE EFlags = 00010202
SegCs = 0000001B SegDs = 00000023
SegSs = 00000023 SegEs = 00000023
SegFs = 00000038 SegGs = 00000000
Dr0 = 0012E940 Dr3 = 10003F4A
Dr1 = 0012EA7C Dr6 = 023EFEF0
I just suddenly started getting this. It is happening in multiple projects.... not *all*. Is that a MFC dll? One common thread seems to be that all the ones that won't compile use MFC.
The debug version is the only one that gives this error. Release works fine...
Any ideas??
Thanks
Adam Clauss
cabadam@tamu.edu
|
|
|
|
|
I just suddenly started getting this. It is happening in multiple projects.... not *all*. Is that a MFC dll?
Ehh, "foo"? No, it's an error (a terminal bug) in the linker.
Reading the MS NG microsoft.public.dotnet.languages.vc I can only come to the conclusion that this release should never have happened. It contains so many (terminal) bugs that it's apparent their so-called QA was on vacation this year also.
For a more authorative answer you should try to post this to that NG (and watch the "maybe fixed in the next version" comment you'll get from MS).
++luck;
/Mike
|
|
|
|
|
Did post it there last night, about the same time I posted here. Haven't got an answer there yet.
Adam Clauss
cabadam@tamu.edu
|
|
|
|
|
Yup, you have hit an internal bug in the linker. Try a rebuild all.
That MSPDB70.DLL is probably a common DLL they use to support the .PDB debug files.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
Did a full rebuild, made no difference. Still fails in the linking 
Adam Clauss
cabadam@tamu.edu
|
|
|
|
|
I do some draw action:
void CMyView::OnPaint()
{
CPaintDC dc(this); // device context for painting
if( m_bDraw == FALSE )
return;
/**/
CDC* pDC = GetDC();
CDC cacheDC;
VERIFY( cacheDC.CreateCompatibleDC( pDC ));
if( m_pBitmap == NULL )
{
m_pBitmap = new CBitmap;
VERIFY( m_pBitmap->CreateCompatibleBitmap( pDC, m_ClientRect.Width(), m_ClientRect.Height() ) );
}
CBitmap* pOldBmp = cacheDC.SelectObject( m_pBitmap );
//Draw background
CRect rect( m_ClientRect );
cacheDC.FillSolidRect( &rect, RGB(255, 255, 255) );
//cacheDC.Rectangle( rect );
cacheDC.Draw3dRect( &rect, RGB( 0, 0, 0 ), RGB( 255, 255, 255 ) );
//!! Some draw actions here, use cacheDC
pDC->BitBlt( m_ClientRect.left,
m_ClientRect.top,
m_ClientRect.Width(),
m_ClientRect.Height(),
&cacheDC, 0, 0, SRCCOPY );
cacheDC.SelectObject( pOldBmp );
cacheDC.DeleteDC();
}
When I open tha "TaskManager", I notice that the memory usage of My app is increase, what's wrong with my draw method?
I'm amumu, and you?
|
|
|
|
|
You are not deleting your m_pBitmap after you are done with it. Your code should look like this:
cacheDC.SelectObject( pOldBmp );
cacheDC.DeleteDC();
m_pBitmap->DeleteObject();
|
|
|
|
|
1.I have tried your method, Now, if I send the WM_PAINT to view on mouse click, it seems no effect, but if I delete the clause, it can work properly.
2.If you choose a new object for CDC, for example CPen, CBrush, etc, must you do the DeleteObject() on exit?
3.If I use the this->GetDC() to draw directly, does it cause memory leak or allocated but not freed? I notice the memory is increasing when use the view's CDC directly.
I'm amumu, and you?
|
|
|
|
|
qf0421 wrote:
1.I have tried your method, Now, if I send the WM_PAINT to view on mouse click, it seems no effect, but if I delete the clause, it can work properly.
Do not send a WM_PAINT message directly, instead do either one of these two things to force a repaint.
InvalidateRect(hWnd, NULL, TRUE);
UpdateWindow(hWnd);
RedrawWindow(hWnd, NULL, NULL, RDW_ERASE | RDW_INVALIDATE | RDW_UPDATENOW);
qf0421 wrote:
2.If you choose a new object for CDC, for example CPen, CBrush, etc, must you do the DeleteObject() on exit?
Yes, if you create a new brush, pen, palette or bitmap, you must select the original GDI Object back into the DC, and then delete your GDI Object that you allocated.
qf0421 wrote:
3.If I use the this->GetDC() to draw directly, does it cause memory leak or allocated but not freed? I notice the memory is increasing when use the view's CDC directly.
You should not call GetDC from inside of your paint handler. You should use BeginPaint, or the CPaintDC (Which internally calls BeginPaint). Then when you are done with a DC you need to release the DC, otherwise it will use up system resources. If you call BeginPaint to get the DC, then you will need to call EndPaint to release the Dc. If you call GetDC, GetWindowDC, or GetDCEx then you will need to call ReleaseDC to free the DC resource.
|
|
|
|
|
Thank you for your help and code, I have got it  ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
I'm amumu, and you?
|
|
|
|
|
You also need to call
pDC->ReleaseDC() ;
Roger Allen
Sonork 100.10016
If I'm not breathing, I'm either dead or holding my breath.
A fool jabbers, while a wise man listens. But is he so wise to listen to the fool?
|
|
|
|
|
How Can I get MFC support in ATL EXE COM Server project?
I want my program like MS Word!
|
|
|
|
|
Help,
The post that I've been dreading. A post that I do not know the answer to. One of my members wants to know how to create custom types, eg. an unsigned int of 8 bits
http://www.jyse.com/phpBB2/viewtopic.php?p=129#129
please help.
|
|
|
|
|
Create a type using bitfields. For example
struct strtype
{
unsigned p1:2;
unsigned p2:3;
unsigned p3:5;
unsigned p4:5;
};
Creates a struct which holds four fields, one of two bits, one of three, and two of five.
Naturally I'd presume you'd create a class and provide all the operators necessary to deal with it, like operator =, operator <, etc.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"I'm somewhat suspicious of STL though. My (test,experimental) program worked first time. Whats that all about??!?!
- Jon Hulatt, 22/3/2002
|
|
|
|
|
Christian, I hope you don't mind me cutting and pasting this onto Jyse.com
|
|
|
|
|
I would think you should probably ask Chris.
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
I've inserted a CDialog as a child of an MDI window with the following code:
m_pDlg = new CMyDlg(FromHandle(m_hWndMDIClient));
m_pDlg->Create(IDD_MYDIALOG, FromHandle(m_hWndMDIClient));
m_pDlg->SetFocus();
m_pDlg->ShowWindow(SW_SHOW);
This works fine however no matter what the title bar stays gray even while I'm actively working inside the dialog.
I reposted this because everyone seemed to be asleep last night when I first posted it. Sorry if you happened to read it twice 
Any ideas?
-Jack
To an optimist the glass is half full.
To a pessimist the glass is half empty.
To a programmer the glass is twice as big as it needs to be.
|
|
|
|
|
AFAIK, only top-level windows can be active. MFC fakes activation for MDI child windows by maintaining an internal active frame, and manually sending WM_NCACTIVATE with the appropriate parameters to the frames. This much i gathered from a quick browse through winfrm.cpp anyway.
If all you care about is getting rid of the gray title bar, you can easily send WM_NCACTIVATE to your dialog to accomplish this; however, you may want to consider using a CFrameWnd-derived class for this purpose, as it will function better along with the other MDI children (CTRL+Tab handling for instance).
Sometimes i only remember, The days when i was young
Nowadays no one remembers when they were young and stupid... ADEMA, The Way You Like It
|
|
|
|
|
Sending WM_NCACTIVATE worked!
Thanks,
Jack
To an optimist the glass is half full.
To a pessimist the glass is half empty.
To a programmer the glass is twice as big as it needs to be.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
