Re: virtual detstruct question when multi derived - C / C++ / MFC Discussion Boards

Re: virtual detstruct question when multi derived

Bob Stanneveld8-Nov-05 5:51

8-Nov-05 5:51

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[^]

Re: virtual detstruct question when multi derived

Maximilien8-Nov-05 6:40

Maximilien

8-Nov-05 6:40

The question is hidden in one of the comment ...

Maximilien Lincourt
Your Head A Splode - Strong Bad

Re: virtual detstruct question when multi derived

Bob Stanneveld8-Nov-05 21:57

Bob Stanneveld

8-Nov-05 21:57

I generally skip illustrations until I've read the question..

Behind every great black man...
... is the police. - Conspiracy brother

Blog[^]

Re: virtual detstruct question when multi derived

toxcct8-Nov-05 6:58

toxcct

8-Nov-05 6:58

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 Big Grin | :-D

TOXCCT >>> GEII power
[toxcct][VisualCalc]

Re: virtual detstruct question when multi derived

Bob Stanneveld8-Nov-05 21:53

Bob Stanneveld

8-Nov-05 21:53

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[^]

Re: virtual detstruct question when multi derived

followait8-Nov-05 15:03

followait

8-Nov-05 15:03

Why will the program be aborted, when ~BBB() is not virtual?

Re: virtual detstruct question when multi derived

Bob Stanneveld8-Nov-05 21:52

Bob Stanneveld

8-Nov-05 21:52

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[^]

Re: virtual detstruct question when multi derived

Blake Miller9-Nov-05 5:43

Blake Miller

9-Nov-05 5:43

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;

CRC-16 Convert to vb.Net

RichardBerry8-Nov-05 3:55

RichardBerry

8-Nov-05 3:55

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

clicking the titlebar

bonosa8-Nov-05 3:54

bonosa

8-Nov-05 3:54

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

Re: clicking the titlebar

Rage8-Nov-05 4:03

Rage

8-Nov-05 4:03

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();

SetWindowText Problem in Release Version

LittleYellowBird8-Nov-05 3:38

LittleYellowBird

8-Nov-05 3:38

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

Re: SetWindowText Problem in Release Version

toxcct8-Nov-05 3:57

toxcct

8-Nov-05 3:57

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

Re: SetWindowText Problem in Release Version

LittleYellowBird8-Nov-05 4:29

LittleYellowBird

8-Nov-05 4:29

Thanks for the interest, the error is,

First-chance exception in PEA Plus.exe: 0xC0000005: Access Violation.

Cheers,

Ali

Re: SetWindowText Problem in Release Version

Rage8-Nov-05 3:57

Rage

8-Nov-05 3:57

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();

Re: SetWindowText Problem in Release Version

David Crow8-Nov-05 4:49

David Crow

8-Nov-05 4:49

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

Re: SetWindowText Problem in Release Version

LittleYellowBird8-Nov-05 4:46

LittleYellowBird

8-Nov-05 4:46

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.

Smile | :)

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

Re: SetWindowText Problem in Release Version

LittleYellowBird8-Nov-05 5:18

LittleYellowBird

8-Nov-05 5:18

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 Smile | :)

Ali

Re: SetWindowText Problem in Release Version

Rage8-Nov-05 5:54

Rage

8-Nov-05 5:54

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();

Re: SetWindowText Problem in Release Version

David Crow8-Nov-05 6:08

David Crow

8-Nov-05 6:08

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

Re: SetWindowText Problem in Release Version

LittleYellowBird8-Nov-05 21:44

LittleYellowBird

8-Nov-05 21:44

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

Re: SetWindowText Problem in Release Version

LittleYellowBird8-Nov-05 22:13

LittleYellowBird

8-Nov-05 22:13

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 Smile | :)

Ali

Re: SetWindowText Problem in Release Version

Rage15-Nov-05 21:18

Rage

15-Nov-05 21:18

Hi Alison,

got this eventually sorted out ?

~RaGE();

Re: SetWindowText Problem in Release Version

LittleYellowBird30-Nov-05 5:14

LittleYellowBird

30-Nov-05 5:14

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 Blush | :O

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 WTF | :WTF:

:-

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 Big Grin | :-D

Ali

cannot open file(image) that saved

sue8-Nov-05 3:01

sue

8-Nov-05 3:01

hi there..have used twain program,but when i tried to open the file back, it not available.anyone have idea about this? firstly when save it automatically save in any files. then i tried to save with putting .bmp or .jpg but it still cannot open. maybe something wrong in DIB coding.someone please explain me why its happen and how to solve it.thanks.
please someone help me, urgent! Frown | :(

- sue -

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.