C / C++ / MFC

9-May-07 9:40

Hi all,
I am quite new to VC++(win32). I have got an application which i want to convert to BORLAND C++(GUI).
Well first of all i am struggling in stepping over the code in VC++.
Well in .Net we use F10 and F11 for step over and step through but in VC++ i guess there is only F10 option i.e. Step over.
Now if i press F10 it doesnt step over to all the functions and all, the program only step over these 3 steps and complete the execution.
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd){

DialogBoxParam(hInstance, MAKEINTRESOURCE(IDD_DIALOGMAIN), NULL, DialogProc, 0);

return 0;

Now you might say to use break point ..well i tried that aswell. i placed break point over 2-3 functions of which i want to see what exactly is going on so after going through all these functions i get an error i.e. "There is no source code available from the current location."

So i guess i am doing something wrong here .Pls suggest me the right way to deal with win32 application.

Thanks
SS

Mark Salsbery9-May-07 10:08

9-May-07 10:08

Software_Specialist wrote:
i placed break point over 2-3 functions

I only see one function call in your posted code, and it's one you won't be able to step into
without a debug version of the operating system.
Once DialogBoxParam() is called the UI is in a modal loop.
To debug at that point you need breakpoint(s) in your DialogProc.

F11 has been step-into for as long as I can remember on VS (I forget the two "step" keys in
Borland).

Mark

"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder

Software_Specialist9-May-07 13:09

9-May-07 13:09

Mark Salsbery wrote:
I only see one function call in your posted code

Mark Salsbery wrote:
To debug at that point you need breakpoint(s) in your DialogProc

So as you said i placed breakpt over DialogProc Function i.e.

<br />
<br />
BOOL CALLBACK DialogProc(HWND hwndDlg, UINT uMsg, WPARAM wParam, LPARAM lParam){<br />
<br />
	int wmId, wmEvent;<br />
<br />
	switch(uMsg){<br />
		case WM_INITDIALOG:<br />
			hWnd = hwndDlg;<br />
			SetWindowText(GetDlgItem(hWnd, IDC_EXT), "TXT");<br />
			CenterWindow(hwndDlg);<br />
			return TRUE;<br />
		case WM_COMMAND:<br />
			wmId    = LOWORD(wParam); <br />
			wmEvent = HIWORD(wParam); <br />
<br />
			switch(wmId){<br />
				case IDOK:<br />
					EndDialog(hwndDlg, IDOK);<br />
					break;<br />
				case IDCANCEL:<br />
					EndDialog(hwndDlg, IDCANCEL);<br />
					break;<br />
				case IDC_BROWSEBMP:<br />
					OnBrowseBmp();<br />
					break;<br />
				case IDC_BROWSEFILE:<br />
					OnBrowseFile();<br />
					break;<br />
				case IDC_COMBIND:<br />
					OnCombindYo();<br />
					break;<br />
				case IDC_BROWSECASEBMP:<br />
					OnBrowseCaseBmp();<br />
					break;<br />
				case IDC_EXTRACT:<br />
					OnExtract();<br />
					break;<br />
			}<br />
			break;<br />
			<br />
		case WM_PAINT:<br />
			<br />
			break;<br />
	}<br />
	return FALSE;<br />
}<br />

When i place break pt over this function it always return FALSE and give me error saying "There is no source code available from the current location".

Now within this fucntiont there are calls to many other functions and which in turn calls to many others. So how can i step through whole application. Where should i place the break point as i also tried placing break pt over functions call with in DialogProc function but nothing seems to be working.

Mark Salsbery wrote:
(I forget the two "step" keys in
Borland).

Its F7 and F8 in borland.

Mark Salsbery wrote:
a debug version of the operating system.

I am not much sure about this.

Please help me out in understanding confusing VC++ Frown | :(

Thanks

Mark Salsbery9-May-07 13:25

9-May-07 13:25

This doesn't have much to do with the difference between Borland and VC.

Where to put breakpoints has to do with Windows message handling - this will be the same no matter
what development environment you use if you are using Win32 APIs.

First, make sure you are doing a debug build, not a release build of your application.

Then...

In your dialogproc, you can put a breakpoint:

1) switch(uMsg){
This will catch every message that goes to the dialog window
2) On any of the function calls.
When a breakpoint is hit you can step into the function with F11.

Mark

"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder

Software_Specialist9-May-07 14:31

9-May-07 14:31

Mark Salsbery wrote:
make sure you are doing a debug build, not a release build of your application.

Yeh it is a debug build only well Debug is in selected mode in MS vs or is there any other way to check for debug mode then let me know if not then yes its in debug mode.

Both the option give me same error.

Mark Salsbery wrote:
1) switch(uMsg){

When cursor goes to next line it returns FALSE and then i get same error

Mark Salsbery wrote:
On any of the function calls.

Nopes same error.

Mark Salsbery9-May-07 14:54

9-May-07 14:54

Software_Specialist wrote:
When cursor goes to next line it returns FALSE and then i get same error

At runtime? With a breakpoint on the switch statement?

Software_Specialist wrote:
Both the option give me same error.

What kind of error??

Mark

"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder

Software_Specialist10-May-07 1:17

10-May-07 1:17

Mark Salsbery wrote:
At runtime? With a breakpoint on the switch statement?

Yeh i placed break pt over switch(uMsg) and when cursor stops at dis pt then next jump it takes to return False and immidiately after crossing close bracket } it gives me error saying "There is no source code available for the current location."

Mark Salsbery wrote:
What kind of error??

"There is no source code available for the current location."

I tried with another VC++ application aswell and it also gives me same kind of error. Ill try copying the code to new project and see if i face same problem or not.

Thanks

Software_Specialist10-May-07 1:38

10-May-07 1:38

Now i tried to re-build the application and it is giving me loads of errors like
Cannot convert parameter 2 from 'const char[6]'to'LPCWSTR'.
And many others similar to the above.
Well i guess this application is written in some older version of VC++ compiler and now when i tried to compile it over VS2005 i got a message saying

"The project 'abc.dsp' must be converted to the current Viusal C++ project format. After it has converted, you will not be able to edit this project in previous version of Visual Studio."

So what does this mean. Is the problem related to this.

Pls let me knw

Thanks

Mark Salsbery10-May-07 4:50

10-May-07 4:50

Software_Specialist wrote:
Now i tried to re-build the application and it is giving me loads of errors like
Cannot convert parameter 2 from 'const char[6]'to'LPCWSTR'.

Somehow you've changed the project settings to make a unicode build. If that's your intention
then you're going to have to fix your code to use Unicode.

Software_Specialist wrote:
"The project 'abc.dsp' must be converted to the current Viusal C++ project format. After it has converted, you will not be able to edit this project in previous version of Visual Studio."

Make a backup of the old project - everything. Just in case you have to go back to the old VC
version. Then you can let the new VS convert the project to be compatible with the current
version.

Mark

"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder

Mark Salsbery10-May-07 4:45

10-May-07 4:45

Software_Specialist wrote:
Yeh i placed break pt over switch(uMsg) and when cursor stops at dis pt then next jump it takes to return False

That's because you'll get alot of messages in your DialogProc that you haven't handled in your
switch statement. A breakpoint there will stop on every message - there will be alot of them.
If you want to catch WM_INITDIALOG, then put a breakpoint at the code after "case WM_INITDIALOG:".

Software_Specialist wrote:
"There is no source code available for the current location."

That's not an error. That means you are trying to step into code that doesn't have debug info
available to match up source code with machine code. In that case you can only step in via
the disassembly window.

There's nothing strange going on. You need breakpoints in YOUR code Smile | :)

Mark

"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder

Nelek13-May-07 19:56

Nelek

13-May-07 19:56

Hi,

sometimes I can't use the debug breakpoints for A or B reason... When that happens... I use AfxMessageBox (...) / MessageBox (NULL,...).

You can not have lots of info, but at least you can determine when it chrashes by moving the message up and down (or with 2 or 3 and different messages). Once you know exactly WHERE, is easier to determine WHAT.

Greetings

--------
M.D.V.

If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?

mla1549-May-07 9:35

mla154

9-May-07 9:35

Hello,
I'm receiving a windows message box (actual name of EXE omitted):
First-chance exception in ______.exe: 0xC0000005: Access Violation
Possible deallocation error? Any other ideas what the problem may be? Any help is appreciated. The disassembly code is shown below (crash at line 44).

38:   void CPlex::FreeDataChain()     // free this one and links
39:   {
00479931   test        ecx,ecx
00479933   je          CPlex::FreeDataChain+15h (00479946)
00479935   push        esi
40:       CPlex* p = this;
41:       while (p != NULL)
42:       {
43:           BYTE* bytes = (BYTE*) p;
44:           CPlex* pNext = p->pNext;
<code>00479936   mov         esi,dword ptr [ecx]</code>
45:           delete[] bytes;
00479938   push        ecx
00479939   call        operator delete (0047f53d)
0047993E   pop         ecx
0047993F   test        esi,esi
46:           p = pNext;
00479941   mov         ecx,esi
00479943   jne         CPlex::FreeDataChain+5 (00479936)
00479945   pop         esi
47:       }
48:   }

Regards,
Mike

Stephen Hewitt9-May-07 14:25

Stephen Hewitt

9-May-07 14:25

Either the caller provied a bad this (but non-NULL) pointer or the linked list structure is corrupt.

Steve

BadKarma9-May-07 22:12

BadKarma

9-May-07 22:12

Looking at this piece of code, i got the shivers. OMG | :OMG:

Well it is MFC code so I shouldn't be surprised.

Use the call stack to get back to get to your code where the real problem probably occurred.
Check for already delete of freed up chunks of memory.

codito ergo sum

FD_ACCEPT event very slow (sometimes)

mla15411-May-07 5:25

mla154

11-May-07 5:25

The problem has been solved. It turns out that I was allocating an incorrect amount of memory for three variables. To sum up,
Old:

double *var1 = new double[20];

Changed to:

double *var1 = new double[correctInt];

Regards,
Mike

od@ananzi.co.za9-May-07 9:20

od@ananzi.co.za

9-May-07 9:20

Hi Guys,

Some background info:
OS - Windows XP Home SP2
IDE - Visual Studio 2002 .NET

I am writing a small client/server application to send/receive data over a network based on WSASocket. Everything is working as the client connects to the server and data is passed successfully between them, except for one issues...

At this stage I am running both the server and client on my development PC and am connecting to 127.0.0.1 or the network ip of 192.168.1.1

Sometimes (about 1 in 10) the establishment of the connection takes a long time, up to 30 seconds. I have now traced the server and client programs to death and now came to the conclusion that the actual firing/receiving of the FD_ACCEPT event sometimes takes very long, for now apparant reason, although usually the FD_ACCEPT is fired within 100ms.

I've traced out the applications to the point where I can show the actual timestamps of the connect function call and the corresponding reception of the FD_ACCEPT event.

To further confuse things it seems that this problem never occurs when I disconnect the network cable. Without the cable I've done about 50 connection tests and they all work fine. When I plug the network cable into the nic every now and then the connection takes an age to establish.

Does anybody have any idea what is going on here ? Is it a nic driver problem ? Is it a winsock problem ? Is it a Windows problem ? Any other ideas ?

Thanks
OD

Re: FD_ACCEPT event very slow (sometimes)

Mark Salsbery9-May-07 10:24