|
Check ::CreateCaret or CWnd::CreateCaret.
Tomasz Sowinski -- http://www.shooltz.com
** Putt knot yore thrust inn spel chequers. **
|
|
|
|
|
Yes, but after first click into the CEdit, the caret stands to vertical line again.
Best regards,
Eugene Pustovoyt
|
|
|
|
|
Eugene Pustovoyt wrote:
after first click into the CEdit, the caret stands to vertical line again
You probably have to handle WM_SETFOCUS - call default implementation first and set your own caret next.
Tomasz Sowinski -- http://www.shooltz.com
** Putt knot yore thrust inn spel chequers. **
|
|
|
|
|
I should not call CEdit::SetFocus() in OnSetFocus()?
There is one more question, various symbols have different width. As to me to adjust width of the caret for any symbol.
Best regards,
Eugene Pustovoyt
|
|
|
|
|
Eugene Pustovoyt wrote:
I should not call CEdit::SetFocus() in OnSetFocus()?
You should, but *before* setting your caret.
Eugene Pustovoyt wrote:
There is one more question, various symbols have different width
You'd probably have to monitor keyboard activity and create new caret whenever it moves to new symbol. Not easy task, IMHO.
Tomasz Sowinski -- http://www.shooltz.com
** Putt knot yore thrust inn spel chequers. **
|
|
|
|
|
Probably, except for pressing the keyboard it is necessary to control the clicks of the mouse. Yes a task not easy.
I shall try, time is not present a way easier, it to realize.
Many thanks for the numerous help to me, including this.
Best regards,
Eugene Pustovoyt
|
|
|
|
|
I seem to have started to generate memory leaks,
really frustrating ones. I think something very strange is going on.
For Example:
in my Splitter class i declare a sub splitter,
m_pwndSplitter = new CJEXSplitter;
it says this is the source of the memory leak but i definately delete it in the destructor:
CJEXSplitter::~CJEXSplitter()<br />
{<br />
int iTemp = 0;<br />
GetColumnInfo(0,m_szFromLeft,iTemp);<br />
m_pwndSplitter->GetRowInfo(0,m_szFromTop,iTemp);<br />
CWinApp * pApp = AfxGetApp();<br />
pApp->WriteProfileInt(_T("SPLITTER"),_T("FROMLEFT"),m_szFromLeft);<br />
pApp->WriteProfileInt(_T("SPLITTER"),_T("FROMTOP"),m_szFromTop);<br />
<br />
<br />
<br />
if (m_pwndSplitter) <br />
delete m_pwndSplitter;<br />
<br />
}
but then it starts saying i have other memory leaks in places I haven't touched like
in my CMainFrame class at
IMPLEMENT_DYNCREATE(CMainFrame, CUIMainFrame)
and in my document class
IMPLEMENT_DYNCREATE(CExplorerDoc, CDocument)
the killer for me is that it says theres a memory leak here to:-
pDocTemplate = new CSingleDocTemplate(<br />
IDR_MAINFRAME,<br />
RUNTIME_CLASS(CExplorerDoc),<br />
RUNTIME_CLASS(CMainFrame),
RUNTIME_CLASS(CExplorerView));
whats going on have i gone mad?!?
Asim Hussain
e: asim@jawache.net
w: www.jawache.net
|
|
|
|
|
Looks like your program is terminated prematurely. Can you put the breakpoint in CYourApp destructor and check if it's actually executed?
Tomasz Sowinski -- http://www.shooltz.com
** Putt knot yore thrust inn spel chequers. **
|
|
|
|
|
I did check on all the ones i declared myself that and it yes they are called. 
Does IMPLEMENT_DYNACREATE declare some memory aswell, if so where is it deleted?
Asim Hussain
e: asim@jawache.net
w: www.jawache.net
|
|
|
|
|
Jawache wrote:
Does IMPLEMENT_DYNACREATE declare some memory aswell, if so where is it deleted?
Not really. IMPLEMENT_DYNCREATE provides the functionality of IMPLEMENT_DYNAMIC (MFC's own, primitive form of RTTI) and adds trivial implementation of virtual function CreateObject.
CreateObject is used by the framework to create documents/views/frames. If you see leaks originating in CYourObj::CreateObject, then something is wrong with app cleanup. Or - maybe you're playing tricks with doc/view architecture.
Tomasz Sowinski -- http://www.shooltz.com
** Putt knot yore thrust inn spel chequers. **
|
|
|
|
|
I've managed to find and put a breakpoint in CDocManager::~CDocManager()
and it isn't called!!!!
I've also just noticed in the debug window:-
ASSERT_VALID fails with NULL pointer. <- HUH??
The thread 0x46C has exited with code 3 (0x3). <-- Hmmm...
Detected memory leaks!
Asim Hussain
e: asim@jawache.net
w: www.jawache.net
|
|
|
|
|
Go one level up and put the bkpt in CWinApp::~CWinApp.
Tomasz Sowinski -- http://www.shooltz.com
** Putt knot yore thrust inn spel chequers. **
|
|
|
|
|
Are you using serialization on some of these objects? If you are then you can get memory leaks by using serialization with pointers like this.
CMyObject *pObject = new CMyObject ;
archive >> pMyObject ; // leak! as CObject create a new object losing the earlier allocated object.
This can be seen in the debugger by stepping over the seriazation line and seeing that the pMyObject pointer value changes.
Roger Allen
Sonork 100.10016
I think I need a new quote, I am on the prowl, so look out for a soft cute furry looking animal, which is really a Hippo in disguise. Its probably me.
|
|
|
|
|
Nope, nothing.
Unless the Document or WinApp performs serialization by itself, but i would imagine I would have noticed the memory leaks earlier.
Asim Hussain
e: asim@jawache.net
w: www.jawache.net
|
|
|
|
|
You are not using global instances of MFC classes?
Global instances destructors are called after reporting memory leaks.
Pavel
Sonork 100.15206
|
|
|
|
|
Nope,
I'm using a number of singleton classes but they aren't the ones with the memory leaks and anyway i use static variables for the instances not pointers.
Whats really confusing me is that VC is saying i have a memory leak in my App::InitInstance where I register the document templates,
pDocTemplate = new CSingleDocTemplate( there is no way that should be the cause of a memory leak because that is part of the framework.
Asim Hussain
e: asim@jawache.net
w: www.jawache.net
|
|
|
|
|
Document template is deleted by CDocManager destructor. CDocManager is an internal MFC class. Can you put breakpoint in CWinApp::~CWinApp - it's appcore.cpp file in mfc\src, at least in VC6. You should see the following code:
if (m_pDocManager != NULL)
delete m_pDocManager;
Maybe for some reason m_pDocManager is NULL?
Tomasz Sowinski -- http://www.shooltz.com
** Putt knot yore thrust inn spel chequers. **
|
|
|
|
|
It is called and m_pDocManager is NULL !
Asim Hussain
e: asim@jawache.net
w: www.jawache.net
|
|
|
|
|
Can you check m_pDocManager at the end of CYourApp::InitInstance?
Tomasz Sowinski -- http://www.shooltz.com
** Putt knot yore thrust inn spel chequers. **
|
|
|
|
|
Yup,
Its declared in AddDocTemplate
and its still NOT null by the end of InitInstance()
Asim Hussain
e: asim@jawache.net
w: www.jawache.net
|
|
|
|
|
Jawache wrote:
and its still NOT null by the end of InitInstance()
This is how it's expected to work.
Now, the advanced breakpoint stuff. Open the breakpoints dialog box (Ctrl+B), select the 'Data' tab and type 'theApp.m_pDocManager' (without apostrophes) in the 'Enter the expression to be evaluated' box. Run the program - you should hit the bkpt in the InitInstance first (this is when it's initialized), then for the second time when it gets nullified.
Tomasz Sowinski -- http://www.shooltz.com
** Putt knot yore thrust inn spel chequers. **
|
|
|
|
|
Argh....
The breakpoint is called when the m_pDocManager is initiated but isn't when it goes back to NULL?? -- Hmm.. soounds like VC itself is buggered...
Asim Hussain
e: asim@jawache.net
w: www.jawache.net
|
|
|
|
|
Jawache wrote:
The breakpoint is called when the m_pDocManager is initiated but isn't when it goes back to NULL
Well, it never goes back to NULL in correctly behaving app. CWinApp::~CWinApp just deletes m_pDocManager. But you're sure that at this point m_pDocManager is NULL when your app exits?
Tomasz Sowinski -- http://www.shooltz.com
** Putt knot yore thrust inn spel chequers. **
|
|
|
|
|
Yes,
It's definately null by the time the destructor is called, but the conditional breakpoint isn't called.
Does the advanced breakpoint work if its a memory overwrite ?
Interesting point -- I put a breakpoint in the connstructor and its actually called twice? I thought there was only ever 1 CWinApp derived object.
Asim Hussain
e: asim@jawache.net
w: www.jawache.net
|
|
|
|
|
Jawache wrote:
I put a breakpoint in the connstructor and its actually called twice? I thought there was only ever 1 CWinApp derived object
Yes, there should be exactly one CWinApp-derived object. Look at the call stack when code hits the breakpoint in constructor.
Tomasz Sowinski -- http://www.shooltz.com
** Putt knot yore thrust inn spel chequers. **
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
