|
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
|
|
|
|
|
Cedric Moonen wrote: t 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.
This problem arises in COM dll not normal DLL, as Memory allocation in Normal DLL is under the Excutable who is calling Function.
similarly, you can see CoTaskMem* series, which deal with same!
"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
|
|
|
|
|
ThatsAlok wrote: This problem arises in COM dll not normal DLL, as Memory allocation in Normal DLL is under the Excutable who is calling Function
Nope, not at all ! Try it: call a function from your dll in which you allocate memory, return this memory and delete it in your program, you will get a crash. I'm sure of that. There are two heap managers: one for the exe and one for the dll. If you try to release memory in your exe that has been allocated by your dll, that won't work.
Also, ask toxcct, he got the problem 
COM dll are just standard dll's (they just provide a set of existing functions and they provide them in a defined way).
Cédric Moonen
Software developer
Charting control
|
|
|
|
|
Cedric Moonen wrote: There are two heap managers: one for the exe and one for the dll.
There can be if the author of a DLL creates a private heap (I have never seen this). However that does not happen by default. There is one and only one default heap across an entire process.
reference[^]
The Process heap is used for allocating blocks if no other heap is used. Language
run times also can create separate heaps within a process. (For example, C run time
creates a heap of its own.) Besides these dedicated heaps, the application program or
one of the many loaded dynamic-link libraries (DLLs) may create and use separate heaps.
COM does not change any of that. If you load a COM dll in process then it shares the same heap. If it is out of process then any memory resources you obtain in the local process from the COM interfaces is marshaled into the local process. This means memory is allocated in the local process and the data has been copied into it from the COM remote process. The local process has NOT been given an address in memory from the remote process.
"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: There is one and only one default heap across an entire process.
Maybe heap manager was not the good term. Ok, they have the same heap but still, you cannot delete memory that hasn't been allocated by the same module:
Both the DLL and the executable file (EXE) maintain their own lists of allocated memory blocks, which they maintain through the malloc memory allocator. The C++ new and delete functions also rely on these lists of memory blocks, so that C++ tends to use dynamic memory allocation more often than C. If the DLL allocates some memory—for example, for the creation of a new instance of a class—this memory is marked in the allocation list of the DLL. If the EXE tries to free this memory, the run-time library looks through its list of allocated memory blocks and fails (usually with a GP fault). Thus, even if the memory between the DLL and the EXE is completely shared, the logic for managing allocation breaks if two modules mix their allocation schemes.
Reference[^]
And furthermore, something that is more relevant than hundred of articles: I experienced this problem. And it was solved by following this guideline: never free mem that has been allocate by your dll in your exe.
And, also, try it yourself, it will be the best proof: make a simple dll with a simple function that only allocate some memory (a char array for example) and return this pointer. Then, in your program, delete this memory. You'll see what happen
Cédric Moonen
Software developer
Charting control
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
