C / C++ / MFC

Re: UPDATE! Re: Debug Assertion Failure wincore.cpp

27-Oct-05 15:06

Just a follow-up. If I comment out the DDX line for the list control, the assertion still fires. And as I noted in the previous response, there are no other controls at all with the same value in the resource.h file.

I'll be back on this project Friday. If you have any ideas please let me know.

Just a note, this program does compile and run in release mode. I know I have to get this fixed in debug mode as well, just some additional info there.

Thanks, Jim

David Crow28-Oct-05 2:23

David Crow

28-Oct-05 2:23

SublimeRide wrote:
If I comment out the DDX line for the list control, the assertion still fires.

Then comment out all of the lines in the DoDataExchange() method and add them back in one at a time until the assertion fires. You can also set a breakpoint on the ASSERT() statement. When that breakpoint is hit, simply look at the call stack to see how the code got to that point.

"Take only what you need and leave the land as you found it." - Native American Proverb

Re: UPDATE! Re: Debug Assertion Failure wincore.cpp

SublimeRide28-Oct-05 10:49

Re: UPDATE! Re: Debug Assertion Failure wincore.cpp

28-Oct-05 10:49

Ok I have some information that may shed some light. There were originally 6 controls on this dialog with member variables (and DDX statements). The reason I thought the list control was the culprit (and it was asserting at the time) was because when I added a member variable, it became the 7th DDX statement and the one failing.

I've since found that if I add 4 member variables (making a total of 10 DDX statements), the program always asserts on the 7th DDX statement, no matter which one is there.

It seems like as soon as any member variables are added beyond the 6 original ones the program had already contained, then the program asserts. I can even put all my new variables at the top of DDX list and they pass fine. The 7th one always asserts no matter what it is. It almost seems as if there is a max amount of controls allowed on the page.

Does this help at all?

Jim

SublimeRide28-Oct-05 20:20

Re: UPDATE! Re: Debug Assertion Failure wincore.cpp

28-Oct-05 20:20

Also, you asked about the call stack. Here it is at the line that asserts. Note, that whatever DDX statement is the 7th one this will assert. Just an FYI from the previous post. There were originally 6 controls with member variables on the dialog. As soon as I add one or more, the 7th DDX statement always asserts.

Call stack:

CWnd::SubclassWindow(HWND__ * 0x00c605c2) line 3866
DDX_Control(CDataExchange * 0x0012e654, int 1131, CWnd & {CWnd hWnd=0x00c605c2}) line 628 + 12 bytes
RunningDlg::DoDataExchange(CDataExchange * 0x0012e654) line 42
CWnd::UpdateData(int 0) line 3109
CDialog::OnInitDialog() line 677 + 10 bytes
RunningDlg::OnInitDialog() line 284
AfxDlgProc(HWND__ * 0x003705e8, unsigned int 272, unsigned int 12846602, unsigned int 12846602) line 35 + 14 bytes
USER32! 77d67b5b()
USER32! 77d6cf23()
USER32! 77d571b9()
USER32! 77d5b7e5()
USER32! 77d6ce12()
USER32! 77d45cc9()
USER32! 77d45ce8()
CWnd::DefWindowProcA(unsigned int 272, unsigned int 12846602, long 0) line 1000 + 32 bytes
CWnd::Default() line 249
CDialog::HandleInitDialog(unsigned int 12846602, unsigned int 12846602) line 621 + 8 bytes
CWnd::OnWndMsg(unsigned int 272, unsigned int 12846602, long 0, long * 0x0012ea60) line 1815 + 17 bytes
CWnd::WindowProc(unsigned int 272, unsigned int 12846602, long 0) line 1585 + 30 bytes
AfxCallWndProc(CWnd * 0x0012f7c4 {RunningDlg hWnd=0x003705e8}, HWND__ * 0x003705e8, unsigned int 272, unsigned int 12846602, long 0) line 215 + 26 bytes
AfxWndProc(HWND__ * 0x003705e8, unsigned int 272, unsigned int 12846602, long 0) line 368
USER32! 77d67b5b()
USER32! 77d6ce12()
USER32! 77d45696()
USER32! 77d58273()
5000000e()

David Crow31-Oct-05 2:33

David Crow

31-Oct-05 2:33

In the OnInitDialog() method, remove the call to UpdateData(). It is hardly, if ever, needed.

"Take only what you need and leave the land as you found it." - Native American Proverb

Re: UPDATE! Re: Debug Assertion Failure wincore.cpp

SublimeRide3-Nov-05 8:11

MFC/COM EXE and DLL debugging

3-Nov-05 8:11

David/John,

I just wanted to bring closure to this thread. The problem is fixed, although I'm not exactly sure how. In the end I deleted the member variable and four controls I had created (two static bitmaps and two static labels). I then added them back to the dialog. This time I added a member variable first to one of the label controls. It compiled and ran without any errors at all. I then began adding member variables to the rest of the controls, again with no errors.

One thing I did differently. Instead of creating the bitmap and associating it with the bitmap led resource, I left it blank. I then created a class variable of HBITMAP type and set it to the led resource. Then used the control's member variable to 'set bitmap' to the HBITMAP.

I'm not sure if those changes were the answer or just deleting and re-adding the controls. Anyway, this vague problem is fixed and it runs in debug mode without assertion failures.

Thanks again for all the help. Jim

Babto20-Oct-05 10:08

Babto

20-Oct-05 10:08

Hi,
I have a MFC/COM exe application which loads the DLL, which is a separate component DLL and not included in main MFC/COM exe project workspace. I want to debug the function calls made by exe on DLL(I have the DLL code).

I built both exe and DLL in Debug mode, registered the DLL and tried to debug. But when the DLL interface call comes the exe not stepping into that DLL call, instead stepping over that DLL call and continuing rest of the execution in the exe.

If someone help me how to debug this DLL call from exe, I will appreciate that.

Re: MFC/COM EXE and DLL debugging

PJ Arends20-Oct-05 11:14

PJ Arends

20-Oct-05 11:14

I would think the problem is that the debugger can not find the source files for the dll. You could try add the path to the dll files to the directories searched by VS. In VS6 it is Tools->Options->Directories. I am sorry I am not sure where it is in VS7.

"You're obviously a superstar." - Christian Graus about me - 12 Feb '03

"Obviously ??? You're definitely a superstar!!!" - mYkel - 21 Jun '04

"There's not enough blatant self-congratulatory backslapping in the world today..." - HumblePie - 21 Jun '05

Within you lies the power for good - Use it!

Re: MFC/COM EXE and DLL debugging

Babto20-Oct-05 11:46

Babto

20-Oct-05 11:46

Thanks a lot. It helped me to findout the problem.

Re: MFC/COM EXE and DLL debugging

C^hris L^osinger20-Oct-05 11:17

C^hris L^osinger

20-Oct-05 11:17

Babto wrote:
not included in main MFC/COM exe project workspace

can you put it into that workspace?

if not, open the DLL's workspace, go to Project / Settings / Debug and give the path to your MFC app in the "Executable for debug session" field. then 'run' your DLL. it will launch your app, and you can set breakpoints in your DLL code (but not in your app's code).

putting the DLL in your app's workspace (even if just temporarily) is really the best way to do it, though.

Cleek | Image Toolkits | Thumbnail maker

I want a Timer fuction on Non UI thread

Anonymous20-Oct-05 9:26

Anonymous

20-Oct-05 9:26

I have a application in which i need a timer event
to fire at some regular interval say 1 to 10 seconds.
But durint this interval other Buttons on the Dialogbox
are not responing .
So i want a method were i can call this timer function by
which it runs on non UI thread.

any idea
thank you

willy_total20-Oct-05 9:35

willy_total

20-Oct-05 9:35

You can use CreateWaitableTimer. It will create a timer that uses events.

RaajaOfSelf20-Oct-05 9:51

RaajaOfSelf

20-Oct-05 9:51

I Guess using CreateWaitableTimer with SetTimer and WaitForSingleObject may block ur thread !

Cause is my effort;
Effect is God's effort

willy_total21-Oct-05 3:39

willy_total

21-Oct-05 3:39

You can't use WaitForSingleObject you have to use MsgWaitForMultipleObjects then Dispatch the message to the other controls while you wait on the timer.

RaajaOfSelf20-Oct-05 9:49

RaajaOfSelf

20-Oct-05 9:49

If you feel teh timer function takes alot of time .then You can do this .

Wherever_Timer_creation_required
{
setTimer(X,Y,MULL)
pthread=AfxCreateThread();
}

OnTimer()
{

pthread->PostThreadMessage(Message)
}

Now you can handle that message in pthread .

Cause is my effort;
Effect is God's effort

bugDanny20-Oct-05 9:55

bugDanny

20-Oct-05 9:55

Use SetTimer() and OnTimer()

Danny

The stupidity of others amazes me!

PJ Arends20-Oct-05 10:00

PJ Arends

20-Oct-05 10:00

SetTimer will work just fine. Pass NULL as the HWND and specify a TimerProc callback function.

Anonymous20-Oct-05 10:27

Anonymous

20-Oct-05 10:27

Thanks
but i have already tried the SetTimer
i have only one option that i didnot wanted
to opt that is create a thread.

Cool | :cool:

PJ Arends20-Oct-05 11:09

PJ Arends

20-Oct-05 11:09

Ok, I misunderstood your question. I thought you were wondering how to set up a timer in a non-ui thread that did not have a window available to handle the WM_TIMER message.

If your timer function is so lengthy that it interferes with the responsiveness of the UI then your only option is to use a seperate thread for it.

Multithread

benjnp20-Oct-05 8:06

benjnp

20-Oct-05 8:06

How will I going to know if a thread is already done on its process? bec what I use is to put a AfxMessageBox at the end of the threaded function.
How will I terminate it prematurely, without waiting for it to finish its task?
--thanks Smile | :)

David Crow20-Oct-05 8:19

David Crow

20-Oct-05 8:19

benjnp wrote:
How will I going to know if a thread is already done on its process?

Right before the secondary thread is about to end, have it post a message to the primary thread. Having the primary thread periodically poll the secondary thread is not a good idea and goes against being asynchronous.

"Take only what you need and leave the land as you found it." - Native American Proverb

benjnp20-Oct-05 14:50

benjnp

20-Oct-05 14:50

can you show me a snippet of sending a message from the secondary thread to the primary thread?

Blake V. Miller20-Oct-05 17:43

Blake V. Miller

20-Oct-05 17:43

PostThreadMessage(PrimaryThreadId, MyThreadMessage, 0, 0);