|
Hi !!!
If you want to detect your Memory Leaks, I wouldn't use the Visual Leaks Detector. It makes some things they are not good in the Runtime. If you want to use VLD, use it only for debugging, belive me. If you don't want to use VLD, I don't know any other Leak Detectors for the Visual Studio 6.0. In Visual Studio .NET 2005 you can do it by using the _CrtMapAlloc in your watches and than you can trigger a breakpoint.
By!!!
-:KNOX:-
|
|
|
|
|
I have three document types in my software. However, when I run the app, it prompts me to decide what type of document to start with; furthermore when I try to use the same resource ID for more than one of my document templates...it also seems to do the same thing. Any ideas? The offending code is listed below.
Thanks in advance.
<br />
pDocTemplate = new CMultiDocTemplate(IDR_PhotonOneTYPE,<br />
RUNTIME_CLASS(CPhotonOneDoc),<br />
RUNTIME_CLASS(CChildFrame),
RUNTIME_CLASS(CPhotonOneView));<br />
if (!pDocTemplate)<br />
return FALSE;<br />
AddDocTemplate(pDocTemplate);<br />
pLWDocTemplate = new CMultiDocTemplate(IDR_MAINFRAME,<br />
RUNTIME_CLASS(CLyghtWayveDoc),<br />
RUNTIME_CLASS(CLyghtWayveFrm),<br />
RUNTIME_CLASS(CLyghtWayveView));<br />
if(!pLWDocTemplate)<br />
return FALSE;<br />
AddDocTemplate(pLWDocTemplate);<br />
pNuDocTemplate = new CMultiDocTemplate(IDR_PhotonOneTYPE,<br />
RUNTIME_CLASS(CNuonDoc),<br />
RUNTIME_CLASS(CNuonFrm),<br />
RUNTIME_CLASS(CNuonFormView));<br />
if(!pNuDocTemplate)<br />
return FALSE;<br />
AddDocTemplate(pNuDocTemplate);<br />
<br />
<br />
CMainFrame* pMainFrame = new CMainFrame;<br />
if (!pMainFrame || !pMainFrame->LoadFrame(IDR_MAINFRAME))<br />
return FALSE;<br />
m_pMainWnd = pMainFrame;<br />
m_pMainWnd->DragAcceptFiles();<br />
EnableShellOpen();<br />
RegisterShellFileTypes(TRUE);<br />
CCommandLineInfo cmdInfo;<br />
ParseCommandLine(cmdInfo);<br />
if (!ProcessShellCommand(cmdInfo))<br />
return FALSE;<br />
pMainFrame->ShowWindow(m_nCmdShow);<br />
pMainFrame->UpdateWindow();<br />
-- modified at 13:46 Thursday 18th May, 2006
|
|
|
|
|
BlitzPackage wrote: when I run the app, it prompts me to decide what type of document to start with
I'm assuming this is undesireable. If so, see here.
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
David,
Thank you so much; because of you I found that answer. I really appreciate it.
What I did was implement the method you provided the link for in an overrided version of the CWinApp::OnFileNew() method.
Thanks again,
BP
|
|
|
|
|
hello again 
Can anybody explain me :
1) What we need stdafx.h and stdafx.cpp files for ?
2) Why are they useful ?
thank you.
|
|
|
|
|
|
Hi !!!
The stdafx file is Precompiled Header file. You can call it Monkey, too. It is only some name from the ActiveX libs.
By !!!
-:KNOX:-
|
|
|
|
|
I'm trying to add a task to the context menu of the Results Pane but can not seem to do this atall!!
I have added a task to the node in the scope pane but when using the same code to add to the results pane it compiles but doesn't do anything. The results pane displays entries that are read into a vector from reading files from a particular directory.
Code I have used is same as below - help!!! 
//This is taken from an platform sdk sample and works on the node but not the results
//add item adds the item to the context menu and the menu command deals with the
//resulting command.
HRESULT CRocket::OnAddMenuItems(IContextMenuCallback *pContextMenuCallback, long *pInsertionsAllowed)
{
HRESULT hr = S_OK;
CONTEXTMENUITEM menuItemsTask[] =
{
{
L"Start vehicle", L"Start the space vehicle",
IDM_START_SPACE, CCM_INSERTIONPOINTID_PRIMARY_TASK, 0, CCM_SPECIAL_DEFAULT_ITEM
},
{
L"Pause vehicle", L"Pause the space vehicle",
IDM_PAUSE_SPACE, CCM_INSERTIONPOINTID_PRIMARY_TASK, 0, 0
},
{
L"Stop vehicle", L"Stop the space vehicle",
IDM_STOP_SPACE, CCM_INSERTIONPOINTID_PRIMARY_TASK, 0, 0
},
{ NULL, NULL, 0, 0, 0 }
};
// Loop through and add each of the menu items
if (*pInsertionsAllowed & CCM_INSERTIONALLOWED_TASK)
{
for (LPCONTEXTMENUITEM m = menuItemsTask; m->strName; m++)
{
hr = pContextMenuCallback->AddItem(m);
if (FAILED(hr))
break;
}
}
return hr;
}
HRESULT CRocket::OnMenuCommand(IConsole *pConsole, long lCommandID)
{
const size_t cchBuffer = 128;
_TCHAR szVehicle[cchBuffer];
// StringCchPrintf and StringCchCopy always null-terminate the destination string.
// However the string may be a truncation of the ideal result (indicated by return value other than S_OK).
switch (lCommandID) {
case IDM_START_SPACE:
iStatus = RUNNING;
break;
case IDM_PAUSE_SPACE:
iStatus = PAUSED;
break;
case IDM_STOP_SPACE:
iStatus = STOPPED;
break;
}
StringCchPrintf(szVehicle, cchBuffer, _T("%s has been %s"), szName,
(long)iStatus == RUNNING ? _T("started") :
(long)iStatus == PAUSED ? _T("paused") :
(long)iStatus == STOPPED ? _T("stopped") : _T("!!!unknown command!!!"));
MAKE_WIDEPTR_FROMTSTR(ptrname, szVehicle);
int ret = 0;
pConsole->MessageBox(ptrname,
L"Vehicle command", MB_OK | MB_ICONINFORMATION, &ret);
return S_OK;
}
Steve
|
|
|
|
|
Hi everybody,
I have a small problem with a CRecordset. I open a dialog-box, where I set some values. When I close the dialog-box with OnOK(), I put all the values in an access-mdb using ODBC.
Right after closing my dialog-box, I need the values in the calling function. So I open my recordset again and read all the values. But the last value is missing.
When I debug my application, all values appear. When I add a button, to get the values from my database, all values appear. When the values are to be read immediately after closing my dialog-box, the last value is missing.
So I think, it is some kind of timing problem. That I read from the database, before all records are written. I tried to reopen the database in my dialogbox right after closing it and I close it again. Now all my records are there (at least mostly). But this is not really elegant.
So, is there any possibility, to wait, until the data is really written in the database after closing it, before reopening it again?
Or am I completely wrong and the problem is something else?
Juergen
|
|
|
|
|
Hi everybody,
I have a big problem when using a CRecordset, that contains a CTime-object.
I use an Access-mdb via ODBC and have a table containing a date/time-row.
I can open this table using CRecordset.
I then do an Edit(), set my values and perform an Update(). Everythings works as expected.
But when I do an AddNew(), set my values and perform an Update(), a access-violation occurs. Debugging shows, that the CTime-object is called with a GetYear(). And here the GPF happens. Since this is somewhere deep inside the MFC, I can not tell, what's going wrong.
Something strange:
I have another table, containing CTime-objects and AddNew() works fine here. I have not found any special differences in my algorithms.
So, can anybody tell me the right questions to help me here?
Juergen
|
|
|
|
|
In the record set's constructor, how are you initializing the CTime member?
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
The Class Wizard generated the constructor and as far as I can see, the CTime is not initialized.
However, before I Update() I call SetFieldNull() to initialize it.
Something special. meanwhile I don't get GPF when at least one record is in my tabel. when the table is empty, I get an GPF, but the record is written correctly. So when starting my application again, everything works.
I add the codesnippet:
Favorit.m_strFilter="User='"+myUser+"' AND Dokument='"+Number+"'";
Favorit.Open();
if(!Favorit.IsBOF())
{
Favorit.MoveFirst();
Favorit.Edit();
}
else
{
Favorit.AddNew();
Favorit.m_User=myUser;
Favorit.m_Dokument=Number;
Favorit.SetFieldNull(&(Favorit.m_Gelesen));
}
Favorit.m_Favorit=bChecked;
Favorit.Update();
Favorit.Close();
The function crashes, when Favorit.Update() is called after Favorit.AddNew().
Here is the declaration of the members in my Recordset:
CString m_Dokument;
CString m_User;
long m_Favorit;
CTime m_Gelesen;
And here is the constructor:
DBFavoriten::DBFavoriten(CDatabase* pdb)
: CRecordset(pdb)
{
m_Dokument = _T("");
m_User = _T("");
m_Favorit = 0;
m_nFields = 4;
m_nDefaultType = dynaset;
}
I don't know, what to do next. This is my first attempt at recordsets and it looks terrible.
Juergen
|
|
|
|
|
Initialize m_Gelesen to CTime(NULL) in DBFavoriten's constructor.
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
Great !
This did the job.
Why does the class wizard not initialize CTime, when everything else is initialized?
Juergen
|
|
|
|
|
hi Friends,
i got different problem.i made dll. after i create new project name called main (i.e new project). i tried linking implictly / explictly. every thing working Fine.
In main() i created Objects Impliectly passing the arguments.(i.e not new because implemented operater overloading.
code like this :
// after include dll
// include header files
int main()
{
char *p;
cls clsobt("./"rrr.ini);
cls1 cls1ob1 = clsobj["section"];
p=cls1ob1["varible"];
cout<
|
|
|
|
|
bujji_bec wrote: delete []p;
delete []p ,should always be associated with new [].
I think,that is only reason why u r getting an Error.
Can u be more specific about the Error ??
Appu..
"If you judge people, you have no time to love them."
|
|
|
|
|
bujji_bec wrote: delete []p; // this statement giving problem
Probably because it is wrong. The previous code gives no evidence that address is a heap address. Even if it is heap based, it was allocated by whatever clsobj is and therefore should be cleaned up by that same class rather than user code.
"What classes are you using ? You shouldn't call stuff if you have no idea what it does"
Christian Graus in the C# forum
led mike
|
|
|
|
|
led mike wrote: it was allocated by whatever clsobj is and therefore should be cleaned up by that same class rather than user code.
That doesn't make sense outside the dll context. You can allocate memory inside a class a release it outside (in the mean function for example). I agree this is ugly and to be avoided by all means but that won't produce any error.
In the context of a dll, it's different because your exe and the dll are two separate processes, so the heap managers are different. Everything that has been created by the dll has to be released by your dll and everything that has been created by your exe has to be released by your exe. If you mix that, you will get troubles 
Cédric Moonen
Software developer
Charting control
|
|
|
|
|
Cedric Moonen wrote: You can allocate memory inside a class a release it outside (in the mean function for example). I agree this is ugly and to be avoided by all means but that won't produce any error.
Yes I agree. I did not mean to imply that it would break, my post was not clear in that regard.
Cedric Moonen wrote: In the context of a dll, it's different because your exe and the dll are two separate processes, so the heap managers are different. Everything that has been created by the dll has to be released by your dll and everything that has been created by your exe has to be released by your exe. If you mix that, you will get troubles
I have no idea what you mean with that statement. You can't "mix" memory addresses across processes because you don't have access to them. Therefore you can't get that "trouble".
His post gives no indication of any remote processes. Even if there is a second process whatever address char *p; is assigned p=cls1ob1["varible"]; is in the current process anyway so I have no clue what you are talking about.
"What classes are you using ? You shouldn't call stuff if you have no idea what it does"
Christian Graus in the C# forum
led mike
|
|
|
|
|
led mike wrote: I have no idea what you mean with that statement. You can't "mix" memory addresses across processes because you don't have access to them. Therefore you can't get that "trouble".
Sorry, maybe it was not clear: your dll has its own heap manager (which manages the heap memory) and the exe has its own heap manager too. If, inside a function of your dll, you allocate memory, it will be allocated by the heap manager of your dll. If you return this pointer to your exe (simply a return from the function) and you try to delete inside your exe, the memory will be released by the heap manager of your exe, which doens't recognize it (of course, because it didn't allocate it). Thus, you got the problem.
Seing his code, if he didn't do any stupid things inside his dll (so if he simply allocate the memory as normal) that's the only thing that can cause the crash.
Cédric Moonen
Software developer
Charting control
|
|
|
|
|
I don't understand what you describe. Could you be more explicit ? What are these clsobt, clobj, cls and cls1 ??
bujji_bec wrote: delete []p; // this statement giving problem
What problem ? You get a crash ? A compile error ? A blue cow is getting out of the screen (this one is highly improbable I think  ).
Anyway, what I think you are doing is using a new inside your dll (you call a function from your dll in which you allocate memory with new), you store this pointer into the variable p and then you try to free the memory. And there BANG, you get an assertion.
It is because the heap manager of your exe and of your dll are different, thus you CANNOT delete memory that has been allocated by your dll and vice-versa. To avoid this problem, use a std::string (but beware you have to link to the same run-time libraries in both of your project settings or you'll get the same problem)
Cédric Moonen
Software developer
Charting control
|
|
|
|
|
Cedric Moonen wrote: A blue cow is getting out of the screen (this one is highly improbable I think ).
no no. this happened to me just two days ago. i was doing a delete [] on something i had allocated with HeapAlloc then resized with _realloc. the cow was pissed, and it broke my desk.
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
Cedric Moonen wrote:
A blue cow is getting out of the screen (this one is highly improbable I think ).
Chris Losinger wrote:
no no. this happened to me just two days ago. i was doing a delete [] on something i had allocated with HeapAlloc then resized with _realloc. the cow was pissed, and it broke my desk.
You should have derived from CGrassEater instead of CVegetarian.
Now you've made the CHolyCow angry!
It's supposed to be hard, otherwise anybody could do it!
Regarding CodeProject: "resistance is pointless; you will be assimilated"
|
|
|
|
|
Roger Stoltz wrote: You should have derived from CGrassEater instead of CVegetarian.Now you've made the CHolyCow angry!
Hope, he doesn't derived CHolyCow from CMenEater.....
Sorry Cedric Just Jokin!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
Cedric Moonen wrote: It is because the heap manager of your exe and of your dll are different, thus you CANNOT delete memory that has been allocated by your dll and vice-versa.
 What in the name of X86 are you talking about! 
"What classes are you using ? You shouldn't call stuff if you have no idea what it does"
Christian Graus in the C# forum
led mike
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
