C / C++ / MFC

26-Sep-06 6:27

Hi I am a newbie to programming and would like to ask a question regarding the debugger. Sometimes when I step into a function the assembler comes up. Why is this? Confused | :confused:

And how do I get around it quickly? I find that by stepping out many many times eventually takes me back to the code where the assembler 1st appeared. Thank you for any information.

Dimitris Vikeloudas26-Sep-06 6:41

26-Sep-06 6:41

Here is how in general a debugger workds: When you build your application in debug mode the executables and/or dlls (or other library files) contain a lot of extra information on top of the actual code. That information are like hyper links to the source C code. Imagine like saying "the following ten assembly commands are in that line of that cpp file". The debuger, in order to display you the source code, it needs the extra 'debug' information and access to the cpp source file.

When the debuger cannot find the source code it displays what it runs in assembly. If you are an assembly guru you might be able to debug the application with that. The usual reasons that goes to assembly are:

i. The application or parts of it are not build in debug mode. Thus, the debuger has no clue where the source is.

ii. The function you step in belongs to the compiler libraries. No company will give you the source C code of them so stepping into them means you go into assembly.

iii. You haven't informed your debuger where the C source code is. Perhaps that has to do with the project settings etc.

minkowski27-Sep-06 0:25

27-Sep-06 0:25

Thanks for the information on why the assembler pops up. I was also wondering on how to exit out of it? I mentioned before that I could step out many many times and eventually it will return to the src code. I was wondering if there is a quicker methods than this? Am I right in saying that you can step out and then immediately close the assembler to return to the src code?

Thanks for your time.

Dimitris Vikeloudas27-Sep-06 1:42

27-Sep-06 1:42

Well by pressing Shift-F11 returns to the caller. I found the usually this works.

Another trick is to use the variables debug window. The context list box contains the stack of the functions. You can see where in the code are you in any depth. Select the level that you 're interested and put a break point immediately after the current step. Then press F5 (run into cursor) to bring you there.

However, the best way is to know where not to step into. If your application is propery build in debug mode try not to step into functions that you do not recognise and especially those that they are known library functions (like printf, calloc etc.) Note that for some MFC classes/functions microsoft provides the source codeto assist you seeing the bug. You will know that by the name of the file that the debuger opens.

minkowski27-Sep-06 2:43

27-Sep-06 2:43

Thank you for your advice. Unfortantely my application is 600,000+ lines and is difficult to know what does what without experimenting so I will use your two first points. But I still find that using SHIFT + F11 does'nt always get you out of the disassembly? Am I doing something wrong with that? Am I right in saying that it should return you to the source immediately?

Thanks again for your tips.
Wink | ;)

Dimitris Vikeloudas27-Sep-06 4:10

27-Sep-06 4:10

Shift-F11 is technically step return which means that it will return to the caller. Sometimes the caller is not directly your source but something else in assembly (perhaps parameters etc). Also I am strongly suspect that your application is not completely build in debug mode.

My hint is try not to enter into assembly (if you can) and make sure that all 600,000 are build in debug mode. If they are sometimes you should be able to see as assembly comments the source C lines. If so then try to see why the debuger cannot find the actual source file. Do you point it to them properly?

minkowski27-Sep-06 4:51

27-Sep-06 4:51

Hello

I went to build -> configurations and made sure the 'debug' version was selected. I then pressed F7 to build a debug version of the project. I then started the application by selecting Go (F5). The application seems to behave itself more when the assembler pops up in that by pressing SHIFT + F11 (step out) it returns to the source. I guess I must have chosen the wrong build or something which is why it was'nt properly working when I tried to step out of the assembler.

But Thanks for your advice.

Big Grin | :-D

Zooming a text

Dimitris Vikeloudas26-Sep-06 6:04

26-Sep-06 6:04

I have a CEdit control and I would like to be able to zoom the text by a floating factor (i.e 0.75 or 1.25 for 80% or 100% zoom). I manage to resize the box to shrink or expand depending on the factor. However, I cannot get a scaled text. I tried the following code

<br />
      // Scale the window.<br />
  XFORM xForm;<br />
<br />
  xForm.eM11 = xForm.eM22 = (FLOAT)m_rZoomingFactor;<br />
  xForm.eM12 = xForm.eM21 = xForm.eDx = xForm.eDy = (FLOAT)0.0;<br />
<br />
  HDC hDC = this->GetWindowDC()->GetSafeHdc();<br />
<br />
  SetGraphicsMode(hDC, GM_ADVANCED);<br />
<br />
  ModifyWorldTransform( hDC, &xForm, MWT_LEFTMULTIPLY );<br />

either by calling it directly or by placing it inside the OnPaint message handler but I get no change.

I also thought that I may need to change the existing font. However, I looked to CFont class and to LOGFONT structure and I haven't seen a simple way to get a font which is a zoomed version of the current font.

How can I zoom a text in a CEdit control? Can I do it but somehow scaling the device context or should I change the font? How do I get a scaled version of the current font?

Note that this change may happen on fly. I 'd like to be able whilst the user is editing the text to zoom in and out. Resizing the box is not a problem but zooming the text is.

Re: Zooming a text

Chris Meech26-Sep-06 9:54

Chris Meech

26-Sep-06 9:54

Dimitris Vikeloudas wrote:
I haven't seen a simple way to get a font which is a zoomed version of the current font.

If you can obtain the LOGFONT structure of the font that the CEdit control uses, the create a font that has an increased point size by your zoom factor, then do a set font call on the CEdit control and then invalidate the window to get it repainted. You will also have to delete the font you created, otherwise it will leak.

Chris Meech

I am Canadian. [heard in a local bar]

Nobody likes jerks. [espeir]

The zen of the soapbox is hard to attain...[Jörgen Sigvardsson]

I wish I could remember what it was like to only have a short term memory.[David Kentley]

Re: Zooming a text

Dimitris Vikeloudas26-Sep-06 22:14

CString memory allocation question

26-Sep-06 22:14

I can obtain the LOGFONT and I know how to handle the font that I 've created. My problem with the LOGFONT (and the CFont class) is that having the structure I do know in which fields should my zooming factor applied (I assume multiplied) to get a bigger or smaller font aesthetically pleasing. Any help on that please?

I thought that another way doing that could be applying a transformation to the device context of the CEdit window (maybe using the ModifyWorldTransform to scale it?) but it does not seems to affect the text in a CEdit. Is it possible to scale a CEdit window??

Re: Zooming a text

Chris Meech27-Sep-06 4:49

Chris Meech

27-Sep-06 4:49

The first field of the LOGFONT structure is height. Increase this using your zoom factor and set the second field, the width, to NULL. The call to CreateFont will calculate an appropriate width, I believe.

KellyR26-Sep-06 5:30

KellyR

26-Sep-06 5:30

In my endless search for memory leaks, I've started to second-guess some things I once thought to be true. I just want to confirm something about CString here, to be certain:

Let's say I have code like this:

std::string displayStr;
displayStr = "Hello";
CString tmp(displayStr.c_str());

Do I need to free any memory here? I'm worried that perhaps in that particular usage of the CString constructor, heap memory is allocated, so I just want to make sure it isn't.

Kelly Ryan

Re: CString memory allocation question

David Crow26-Sep-06 5:31

David Crow

26-Sep-06 5:31

When tmp goes out of scope, memory will be freed.

"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15

"Judge not by the eye but by the heart." - Native American Proverb

Re: CString memory allocation question

KellyR26-Sep-06 5:35

KellyR

26-Sep-06 5:35

Great, thanks.

Converting character to its ascii

samita_friendly26-Sep-06 5:22

samita_friendly

26-Sep-06 5:22

How do I take each character from an array, convert it into its ascii and store the values into another array? Someone please respond. Thanks.

samita_friendly

toxcct26-Sep-06 5:25

toxcct

26-Sep-06 5:25

a char already contains the ascii value...

char c = 'd';
int i = c; //ascii code of the 'd' character...

TOXCCT >>> GEII power

[VisualCalc 3.0 updated ][Flags Beginner's Guide new! ]

samita_friendly26-Sep-06 5:26

samita_friendly

26-Sep-06 5:26

But, I have an array of about 100 characters in it. How do I convert all of them into ascii?

David Crow26-Sep-06 5:32

David Crow

26-Sep-06 5:32

One at a time. What's the problem?

"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15

"Judge not by the eye but by the heart." - Native American Proverb