|
I use a structure which maps a name to a variable address and type
typedef struct
{
const char* name;
void* value;
ParamDataTypes type;
} ParamData;
ParamData paramData[] =
{
"var1", &m_Var1, PT_ULong,
"var2", &m_Var2, PT_Float,
"var3", &m_Var3, PT_String,
};
Then all you need is a function which can loop through the paramData and do the proper conversion from input type to PT_Whatever.
Todd Smith
|
|
|
|
|
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. 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
