|
Hi
I'm new to this.
I'm debugging a simple Visual C++ 6 single document application and I must have inadvertently set a debug option to step into code other than my own source code. Instead of stepping though the source in my project, it's stepping throught the classes and assembler code that I'm not interested in.
How do I turn this off so I just step through my own code?
Ivor 
|
|
|
|
|
you have 2 options
1. Use Shift+F11 (See msdn) to skip the function. This is what most of us are doing.
2. Remove .pdb files for all modules you do not want to see in debug. This option is a very bad option because it could mess up your VC installation, but you still can do it. Try to avoid .pdb for mfc, atl, stl, crt and other MS libraries.
|
|
|
|
|
Thanks
So it's not me then 
I couldn't find the option because it's not there 
|
|
|
|
|
Need an example on how to dynamically load a dialog from an MFC extension dll?
|
|
|
|
|
Getting this warning when I compile some code that I developed under VC 6:
e:\Microsoft Visual Studio .NET\Vc7\include\useoldio.h(29) : warning C4995: '_OLD_IOSTREAMS_ARE_DEPRECATED': name was marked as #pragma deprecated
I believe I know *what* this warning means... somewhere somebody is including <iostream.h> instead of the more "standard" <iostream>. But I can't for the life of me figure out where this is happening. It has to be deep in some nested include somewhere.
The warning, though, comes up in a Visual header (useoldio.h) and I have no indication of what line in *my* code that is actually including the wrong file. Any ideas on how to figure this out? Of course this isn't life-threatening, but it is a nuisance.
Even a broken clock is right twice a day.
|
|
|
|
|
old standard:
#include <iostream.h> // this is what generated the warning
new standard
#include <iostream>
look for std headers in your project everything which has <[stdheader].h> might be the problem
|
|
|
|
|
Yeah, I know that. I may not have made it clear thouugh - I can't seem to find the old std headers in any of my source files. That means it's buried somewhere, but I don't know any good way of figuring out what's doing it.
Even a broken clock is right twice a day.
|
|
|
|
|
I did:
RECT rect;
GetClientRect(this,&rect);
and got
C:\ATRAIN2\VcDemoResizerTHB\DialogDemo1.cpp(59) : error C2660: 'GetClientRect' : function does not take 2 parameters
though I found:
The GetClientRect function retrieves the coordinates of a window's client area. The client coordinates specify the upper-left and lower-right corners of the client area. Because client coordinates are relative to the upper-left corner of a window's client area, the coordinates of the upper-left corner are (0,0).
Syntax
BOOL GetClientRect( HWND hWnd,
LPRECT lpRect
);
Appreciate your help,
ns
|
|
|
|
|
That is the WIN32 API routine. The MFC routine when used inside of a class method just takes the rect as the single argument.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Got it! So MFC sort of knows which is being used - the API one or thh CWND one.
Appreciate your help,
ns
|
|
|
|
|
use
GetClientRect(&rect);
You must to be ussing the MFC class version.
If you want to use the WINDOW version mas to use
::GetClientRect(this,&rect);
Carlos Antollini.
Pi Five[^]Creator
Sonork ID 100.10529 cantollini
|
|
|
|
|
Finally, you use an & in the argument, and MSDN says just the rect, no &......it compiles either way. Which is right?
Appreciate your help,
ns
|
|
|
|
|
read(anything MSDN, book, C++ standard) about c++ scope resolution operator.
|
|
|
|
|
Depends.
If you use a variable type RECT you must to use & becuase you must to use a long pointer to RECT LPRECT
for example
RECT rc;
::GetWindowRect(hwnd, &rc);
or
LPRECT rc;
::GetWindowRect(hwnd, rc)
Best Regards
Carlos Antollini.
Pi Five[^]Creator
Sonork ID 100.10529 cantollini
|
|
|
|
|
I have a modeless dialog that can be stretched. If I want to know its height and length how do I get this? If I have a button on this dialog and want its dimensions hwo do I ?
I'm reading about GetCLientRect and GetWindowRect but am not sure how the functions know whose dimensions they are getting since both take the rect structure as arhgument but arent told which object they are getting the measurements for....
CWnd::GetWindowRect
void GetWindowRect( LPRECT lpRect ) const;
Appreciate your help,
ns
|
|
|
|
|
You can do the following:
CRect rc;
GetWindowRect(rc);
int Width = rc.Width();
int Height = rc.Height();
Also You can use GetWindowPlacement();
If you want to resize the Dialog, you mas to use The MoveWindow Function then of put the correct values into the CRect class...
Best Regards
Carlos Antollini.
Pi Five[^]Creator
Sonork ID 100.10529 cantollini
|
|
|
|
|
I'm not exactly sure I understand you correcly ...
GetWindowRect : Gets the window ( your dialog ) size in window coordinate, from the parents point of vue, top left relative to the parent.
GetClientRect : Gets the client window ( your dialog ) size in local coordinate, usually the inside of the dialog; the top left is (? ) 0,0.
They get the size of the current object's scope.
void MyDialog::DoSomething()
{
CRect Rect;
GetClientRect( Rect );
this->GetClientRect( Rect );
GetWindowRect( Rect );
this->GetWindowRect (Rect );
}
or from the dialog caller :
...
myDialog.GetWindowRect( Rect );
myDialog.GetClientRect( Rect );
GetClientRect and GetWindowRect work for any CWnd classes.
Max.
|
|
|
|
|
Ah! MAny thanks. SO I guess I shouldnt be trying to use the GetCliuentREct in mSDN that has two parameteers.....
Thanks
Appreciate your help,
ns
|
|
|
|
|
GetWindowRect returns the location of the whole window on the screen. GetClientRect just returns the client area inside of the window. For most windows, the client area rect will look like (0,0)-(w,h) where w and h is the width and height. To be 100% correct, to get the width and height of a rectangle from a rect in the form of (l,t)-(r,b) would be width = r-l and height = b-t.
But since dialog boxes usually contain border, the size of the rect returned by GetWindowRect will be larger than GetClientRect.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
I'm slowly building an interpreter using flex and bison, but it's starting to look like the only input method bison supports is through C-style FILEs (either opened explicitly or stdin).
Does anyone know if it's possible or reasonable to have bison parse input from an arbitrary string in memory? If so, can you point me at a resource that might describe the technique?
PS I have yet to read the manual thoroughly since I'm not to the point where I need to reroute input yet... If it's plainly in the manual, just call me an idiot and I'll figure it out myself. 
J
May the bear never have cause to eat you.
|
|
|
|
|
As usual, I figured it out myself. Turns out there's a whole section on it in the book I have.
We need an "I feel stupid" emoticon...
J
May the bear never have cause to eat you.
|
|
|
|
|
Jamie Hale wrote:
We need an "I feel stupid" emoticon...
Please, no more gfx.
What's more important is that we do need to teach people (even if by LARTing) to read the documentation before going public with their ignorance.
|
|
|
|
|
Mike Nordell wrote:
Please, no more gfx.
It was a joke.
Mike Nordell wrote:
What's more important is that we do need to teach people (even if by LARTing) to read the documentation before going public with their ignorance.
Your blunt replies have finally fallen on accepting ears.
I notice you have striven, throughout most of your recent posts, to point out other peoples' ignorance. Not suprisingly, they haven't been very appreciative.
I, on the other hand, pointed out my ignorance before you. I even warned you of it in my initial post. Thank you for reinforcing my claims. I know now that I am truly on the right path.
Now that that's out of the way, might I suggest you reconsider your trolling attempts? Going out of your way to be more condescending than helpful is only going to piss people off, and likely contribute to angst and stress-related illnesses for you.
It's amazing the new world that opens up to you when you stop thinking of others as mere pedestrians, and instead look at them as fellow humans.
I wish you luck in your journey.
J
So much hatred - Such a short life
|
|
|
|
|
Jamie Hale wrote:
Your blunt replies have finally fallen on accepting ears.
Yeah, ain't I an a**hole?
At least I try to help the ones asking to help themselves instead of serving the answers on silver plates, which teach them nothing but "if I ever have a question, I won't bother to even look it up in the documentation since I can always bug it out of someone else".
I notice you have striven, throughout most of your recent posts, to point out other peoples' ignorance.
Then you have seen something that's never been my intention. My intention has been, however blunt (depending on the level of percieved stupidity, obviousness, or even time of day) to make those people first search for answers that are (as I have sometimes pointed out) available in either MSDN or on Google.
It is expected (by me, and many others) that someone asking a question that has an answer (i.e. not to spur a discussion) on a message board, in a newsgroup or any other publicly available "board", has first done its own research.
I'm sorry this matter has affected you in such a negative way, but I stand firm in my opinion that people should first search publicly available sources of information.
I wish you luck in your journey.
I wish thee the same, oh seeker of the goodness in humanity. 
|
|
|
|
|
Mike Nordell wrote:
Yeah, ain't I an a**hole?
Nah, just blunt.
Upon re-reading my reply, I'm forced to admit I was in an odd place that day.
I have worked with people from both ends of the spectrum. Some who simply cannot think for themselves (take the guy in the next cubicle - please - "How do I print from Visual Studio?"), and others who just refuse to take advantage of someone else's experience. And while I resent (and I resent the resentment...) helping the doofuses (doofae?) out, I'm not sure that flat-out beligerance is the solution. At least it isn't for me.
I guess it comes down to giving the querent the benefit of the doubt. In the situation with the printing question, given that this wanker insists he's been programming for 10 years, it's clear he's a bit of an idiot and deserves no sympathy. I quietly explained, "Same as every other Windows app." and let it go. But in other situations, it's not always cut and dry.
Take my question, for instance. I had been tweaking my yacc grammar for a few days, periodically going to my reference manual and the online tutorials. All such reference material (save the one small section I later found) assumes input comes from files. And since the tool is really for building compilers and makes it easy to build command line applications, I was curious as to the number of hoops I would have to jump through to route something other than a file through the parser. I had looked through a fair amount of reference material, and just hadn't come across an answer.
Sure, I didn't explain this in my question, and sure I didn't read ALL reference material, and so I can see how ignorance might be assumed. But I like to think I know what I'm doing. I've written a few articles here. I've helped out from time to time in the forums. I'm quite willing to toot my own horn...
Now that I think about it, I guess I made an incorrect assumption as well. I assumed that the person replying would recognize my name and assume I wasn't being a complete slack-bag.
I guess I just got a little incensed that you assumed ignorance. No worries. As I might have mentioned, I tend to do the same. Trying to break myself of the habit though...
Mike Nordell wrote:
I wish thee the same, oh seeker of the goodness in humanity.
That whole "high expectations for humanity" thing was an old bio. I've moved on. Pretty much no hope now.
J
May the bear never have cause to eat you.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
