|
|
I'm sure that you have a question of some degree in relation to the code you posted. I figure that you have a question about virtual destructors in relation with multiple inheritance, but please hint me, where is your question?
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
The question is hidden in one of the comment ...
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
I generally skip illustrations until I've read the question..
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
Bob Stanneveld wrote: but please hint me, where is your question?
as his question was hidden, i was also asking for it with criticism and "hidden style" too 
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
I think that people should take more time to post a clear question, instead of hiding it in something that is supposed to be an inllustration.
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
Why will the program be aborted, when ~BBB() is not virtual?
|
|
|
|
|
Hello,
I think that when the runtime destroys your object, it sees that it is instantiated from multiple classes (the inheritance). The runtime then starts to look for all appropriate destructors in the virtual function table. This is done because the runtime must call more than one destructor. When the runtime detects that one of the destructors is 'missing' in the v-tables, it crashes since it doesn't know what to do.
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
Yeah, if you don't have virtual destructors, then your delete better be to a pointer of the proper class allocation.
For example, with ~BBB non-virtual, this will not crash:
CCC* pbbb = new CCC;<br />
delete pbbb;
So, if you can't afford virtual destructors, then you better cast your delete operation to a pointer of the correct type.
For example, with ~BBB non-virtual, this DOES NOT crash:
BBB* pbbb = new CCC;<br />
CCC* pccc = (CCC*)pbbb;<br />
delete pccc;
|
|
|
|
|
Hi
Please could someone help me to convert the following to Visual Basic.. It is a CRC16 algorithm using the polynomial (x16 + x15 + x2 + 1) used for very short strings.
Tks
Richard
static unsigned BitsSet (unsigned char ch)
{
unsigned n; n = 0;
while (ch)
{
n += (ch & 1);
ch >>= 1;
}
return(n);
}
unsigned CRCof (const char *message, unsigned len)
{
unsigned i;
unsigned crc;
unsigned char k;
crc = 0;
for (i=0; i
|
|
|
|
|
When you click on a Dialogs title bar what event is triggered? How does one detect if the title bar has been clicked?
thanks,
sb
|
|
|
|
|
WM_LBUTTONDOWN is sent for sure, maybe WM_NCHITTEST ca nbe intercepted (check for OnNcHitTest whose return value is HTCAPTION when the title bar was clicked). To be sure, try with Spy++,
~RaGE();
|
|
|
|
|
I am creating an edit control like this .....
editPointSize.Create(ES_CENTER|WS_VISIBLE|WS_CHILD,rectOffScreen, this, ID_EDIT_POINT_SIZE);
Then I am setting up the text in it like this .....
CString strData;<br />
strData.Format("%d", nPointSize);<br />
editPointSize.SetWindowText(strData);
If I run this under the debugger its OK, but if I compile and run a release version it crashes, any ideas?
Many Thanks,
Ali
|
|
|
|
|
Alison Pentland wrote: if I compile and run a release version it crashes
what is the error message when the application crashes please ???
TOXCCT >>> GEII power
[toxcct][VisualCalc]
-- modified at 9:57 Tuesday 8th November, 2005
|
|
|
|
|
Thanks for the interest, the error is,
First-chance exception in PEA Plus.exe: 0xC0000005: Access Violation.
Cheers,
Ali
|
|
|
|
|
Alison Pentland wrote: editPointSize.Create(ES_CENTER|WS_VISIBLE|WS_CHILD,rectOffScreen, this, ID_EDIT_POINT_SIZE);
Does this always succeed ? Try and messagebox its result.
~RaGE();
|
|
|
|
|
Alison Pentland wrote: I am creating an edit control like this .....
editPointSize.Create(ES_CENTER|WS_VISIBLE|WS_CHILD,rectOffScreen, this, ID_EDIT_POINT_SIZE);
Why are you creating the control at runtime rather than design time?
"Take only what you need and leave the land as you found it." - Native American Proverb
|
|
|
|
|
Reply to Rage (CP very very slow & I can't seem to reply to the correct message!)
Great idea, here's the code I tried...
if(editPointSize.Create(ES_CENTER|WS_VISIBLE|WS_CHILD, rectOffScreen, this, ID_EDIT_POINT_SIZE))<br />
AfxMessageBox("Edit OK");<br />
else<br />
AfxMessageBox("FAIL FAIL FAIL!!!");
It always returned TRUE, 'Edit OK' and still crashed when I did SetWindowText.
 Thanks for the help, I'm not sure what to do next, so if you have any more ideas they will be gratefully received.
Cheers,
Ali
-- modified at 11:37 Tuesday 8th November, 2005
|
|
|
|
|
Erm, good question.
I am using MFC VC++ 6, and creating the edit box in the view window. I always create controls in dialog boxes at design time but I always create them in the view window at runtime. I have always done it that way, not sure if its right but it normally works. To be honest I don't know how else to do it, the designer thingy is only for dialog boxes isn't it?
Thanks for the input, any suggestions gratefully received
Ali
|
|
|
|
|
Alison Pentland wrote: SetWindowText
Since it is release, how do you know that it crashes when you do SetWindowText ? I suppose it works when you comment it out ?
So, if the creation of the edit control works, it is assigned a handle, and SetWindowText should not crash. Let's see what we have:
1. SetWindowText is not called before the edit box creation, since you see your messagebox before the failure.
2. The code works in debug -> have you used a #if __DEBUG somewhere, or made an ASSERT(md.InitMyVariable()) that would drop any intialisation in Release mode ?
3. Are you sure that SetWindowText fails ?
4. Have you created your edit control editPointSize locally (on the stack) in function A, and called SetWindowText in function B, so that the edit control gets erased at the end of A and does not exist anymore at B point ?
5. Temporarily enable debugging in release build using the project options, maybe it can help.
6. Check on CP for the article named "Surviving the Release" or something like this (sorry no time for a link, I got to leave in a couple of minutes), there may be good hints in there.
Good luck,
~RaGE();
|
|
|
|
|
Why not just use a CFormView? With it, you can have a view with controls that are normally placed on dialogs.
"Take only what you need and leave the land as you found it." - Native American Proverb
|
|
|
|
|
Hi Rage,
Thanks for your reply.
Rage wrote: 1. SetWindowText is not called before the edit box creation, since you see your messagebox before the failure.
Definetly not, I have checked this because I thought that maybe the cause too.
Rage wrote: 2. The code works in debug -> have you used a #if __DEBUG somewhere, or made an ASSERT(md.InitMyVariable()) that would drop any intialisation in Release mode ?
No, I am fairly sure that I haven't used anything like that, I don't recall ever using them and no one else has worked on this code.
Rage wrote: 3. Are you sure that SetWindowText fails ?
I use that line twice, once at initialisation and later to update the edit control. I used a messge box to determine where it failed and it was at the SetWindowText in the initialisation. If I remove that line it gets through the initialisation and runs ok until I try to update the edit control, then it fails. So I am pretty sure SetWindowText is the closely related to the problem.
Rage wrote: 4. Have you created your edit control editPointSize locally (on the stack) in function A, and called SetWindowText in function B, so that the edit control gets erased at the end of A and does not exist anymore at B point ?
No, the edit control is a member of the class and therefore it should be fine (however, I have declared it in a seperate include file to try to keep my class tidy, it should not be a problem but I will check it out)
Rage wrote: 5. Temporarily enable debugging in release build using the project options, maybe it can help.
I've never done this, I will give it a try.
Rage wrote: 6. Check on CP for the article named "Surviving the Release" or something like this (sorry no time for a link, I got to leave in a couple of minutes), there may be good hints in there.
Good idea, now you mention it I've seen an article like that, I will find it up.
Also, your suggestions have made me wonder a bit more about the problem. I have lots of controls created like this, but commented them out to concentrate on one problem at a time. I think I will try to discover if the problem is with all edit controls or just some (or just one) of them.
Thanks for your help, CP was very slow for me yesterday and I also have to leave but you have been really helpfull,
Rage wrote: Good luck,
Thanks,
Ali
|
|
|
|
|
Hi David,
Thanks for the idea, I most probably could do that, but I don't understand why I am having a problem with SetWindowText the way I am doing it.
Even if I did change my whole method I think I would like to get to the bottom of this problem because I need to know if I am doing something silly or if I have a fundamental misunderstanding of what I am doing, because I think what I am doing should work.
Anyway, thanks for the advice - I will keep it in mind
Ali
|
|
|
|
|
Hi Alison,
got this eventually sorted out ?
~RaGE();
|
|
|
|
|
Hi ~RaGE();
Sorry its taken me so long to reply, I haven't been around for a while.
Yes I have sorted it out and it turned out to be my own silly error 
It turned out not to be in SetWindowText but in a function called "OnEditPointSize". It was called when I set the text size.
Instead of declaring it like this:-
void CPPlusView::OnEditPointSize(void)
I had declared it like this  :-
void CPlusView::OnEditColourBands(NMHDR* pNMHDR, LRESULT* pResult)
Its my own fault, I've used cut & paste when I first created the function and forgotten to change the parameters. It actually crashed when it left the function, I guess it messed up the stack.
I found it by starting the simplest program I could, then I recreated the problem by adding code in from my application. Then I had so little code to look through I soon found it.
Thanks for the help, you gave me some new ideas to try which was definetly a big help. Sometimes I get stuck with a bug and I just can't think how to find it!
Thanks Again
Ali
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
